Skip to content
This repository was archived by the owner on Nov 23, 2020. It is now read-only.

Clean Architecture

Axel Le Bot edited this page Mar 22, 2017 · 7 revisions

Commencer

Nous savons que l'écriture de logiciels de qualité est difficile et complexe: il ne s'agit pas seulement de satisfaire les exigences, devrait également être robuste, maintenable, vérifiable et suffisamment flexible pour s'adapter à la croissance et le changement. C'est là que "la Clean Architecture" apparaît et pourrait être une bonne approche à utiliser lors du développement d'une application logicielle.

L'idée est simple: la Clean Architecture représente un groupe de pratiques qui produisent des systèmes qui sont:

  • Indépendant des Frameworks.
  • Testable.
  • Indépendant de l'Interface.
  • Indépendant de la base de données.
  • Independent de tout organisme externe.

Certains des avantages sont:

  • Trouver et réparer les bugs plus rapidement et plus facilement.
  • Extraire la logique métier des contrôleurs de vue en interacteurs.
  • Extraire la logique de présentation, des contrôleurs de vue, en des présentateurs.
  • Modifier les comportements existants en toute confiance avec des tests unitaires rapides et maintenables.
  • Écrivez des méthodes plus courtes avec une seule responsabilité.
  • Découpler les dépendances de classe avec les limites clairement établies.

Clean Architecture

Il n'est pas obligatoire d'utiliser seulement 4 cercles (comme vous pouvez le voir sur l'image), car ils ne sont que schématiques mais vous devez prendre en considération la règle de dépendance: les dépendances de code source ne peuvent que pointer vers l'intérieur et rien dans un cercle intérieur ne peut savoir quelque chose sur quelque chose dans un cercle extérieur.

Voici un vocabulaire pertinent pour vous familiariser et mieux comprendre cette approche:

  • Entités (Entities): Il s'agit des objets métier de l'application.
  • Cas d'utilisation (Use Cases): Ces cas d'utilisation orchestrent le flux de données vers et à partir des entités. Sont également appelés Interactors.
  • Adaptateurs d'interface (Interface Adapters): Cet ensemble d'adaptateurs convertit les données du format le plus pratique pour les cas d'utilisation et les entités. Présentateurs et contrôleurs appartiennent ici.
  • Cadres et Pilotes (Frameworks and Drivers) : C'est là que vont tous les détails: interface utilisateur, outils, framework, etc.

Approche architecture reactive

http://fernandocejas.com/2015/07/18/architecting-android-the-evolution/

Clone this wiki locally