Outils pour utilisateurs

Outils du site


conception:ddd:toc

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision
Révision précédente
conception:ddd:toc [2018/02/05 15:07] sgariepyconception:ddd:toc [2022/02/02 00:42] (Version actuelle) – modification externe 127.0.0.1
Ligne 24: Ligne 24:
   * La courbe d'apprentissage : nouveaux principes, nouveaux patterns, nouveaux processus.   * La courbe d'apprentissage : nouveaux principes, nouveaux patterns, nouveaux processus.
   * Seulement pertinent s'il existe une certaine complexité dans le problème à résoudre (//business domain complexity//).   * Seulement pertinent s'il existe une certaine complexité dans le problème à résoudre (//business domain complexity//).
 +    * Pas nécessaire pour des applications qui font du CRUD ou qui sont //data-driven//.
 +  * Convaincre une équipe ou une entreprise à l'utilisation et les bénéfices du DDD.
 +  
  
  
Ligne 32: Ligne 35:
   * Sub-domains: Applications ou fonctionnalités séparées que le logiciel doit supporter ou intéragir avec.   * Sub-domains: Applications ou fonctionnalités séparées que le logiciel doit supporter ou intéragir avec.
   * Bounded-context: Une responsabilité précise, avec des frontières explicites qui séparernt des autres parties du système.   * Bounded-context: Une responsabilité précise, avec des frontières explicites qui séparernt des autres parties du système.
-  * Context-mapping: Le processus de délimiter les contextes délimités (_bounded context_)+  * Context-mapping: Le processus de délimiter les contextes délimités (//bounded context//), leurs relations entre chacun. 
 +  * Shared kernel: Partie du modèle qui est partagé par deux ou plusieurs équipes, qui sont d'accord pour ne pas le changer sans collaborer. 
 +  * Ubiquitous language: Un langage qui utilise des termes du modèle du domaine que les développeurs et les experts du domaine utilisent pour communiquer à propos du système.
  
 +> The Domain Layer is responsible for representing concepts of the business, information about the business situation, and business rules. State that reflects the business situation is controlled and used here, even though the technical details of storing it are delegated to the infrastructure.This layer is the heart of business software.
 +
 +-- Eric Evens, //Domain-Driven Design//
 +
 +====== Elements of a Domain Model ======
 +
 +
 +===== Anemic vs Rich =====
 +
 +Anemic focalise sur l'état d'un objet, alors que le **rich domain models** focalise sur le comportement et les règles d'affaires du domaine.  Quoique le modèle anémique peut être partfait pour le CRUD, celui-ci constitue un anti-pattern dans le contexte du DDD.
 +
 +
 +
 +====== Aggregates ======
 +
 +
 +
 +
 +
 +
 +====== Sources ======
 +
 +  * [[https://app.pluralsight.com/library/courses/domain-driven-design-fundamentals/table-of-contents|Domain-Driven Design Fundamentals]]
 +
 +
 +===== Ressources =====
 +
 +  * [[https://khalilstemmler.com/articles/domain-driven-design-intro/|An Introduction to Domain-Driven Design - DDD w/ TypeScript]]
 +  * [[https://dev.to/remojansen/implementing-the-onion-architecture-in-nodejs-with-typescript-and-inversifyjs-10ad|Implementing SOLID and the onion architecture in Node.js with TypeScript and InversifyJS ]]
 +
 +
 +==== Exemples ====
 +
 +  * [[https://github.com/kgrzybek/modular-monolith-with-ddd|Modular Monolith with DDD]], [[https://www.infoq.com/news/2019/09/design-ddd-modular-monolith/|Design and Implementation of a DDD-Based Modular Monolith ]]
  
  
  
  
----- 
  
-Source : [[https://app.pluralsight.com/library/courses/domain-driven-design-fundamentals/table-of-contents|Domain-Driven Design Fundamentals]] 
conception/ddd/toc.1517839673.txt.gz · Dernière modification : 2022/02/02 00:42 (modification externe)