Domain Driven Design (DDD)
- 1. Domain Driven Design Tom Kocjan I3Logix Inc.
- 2. What is DDD? • It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. • A Model driven software design approach used to tackle the complexity of software projects. • Collection of principles and patterns that help developers craft elegant systems.
- 3. Domain A sphere of knowledge or activity. What an organization does and the world it does it in. Model A system of abstractions that describes selected aspects of a domain and ignores extraneous detail. Explains a complex domain in a simple way. A model is a distilled form of domain knowledge, assumptions, rules and choices. Definitions
- 6. DDD is a Set of Driving Principles • Speak a Ubiquitous Language within an explicitly Bounded Context. • Explore models in a creative collaboration of domain practitioners and software practitioners. • Focus on the Core Domain. • Model and implementation are bound... developers are also responsible for the model.
- 7. Ubiquitous Language A language structured around the domain model and used by all team members to connect all the activities of the team with the software. Use it consistently in speech, documentation, diagrams and code. A Change in Ubiquitous Language <=> Change in Model and Code. Ubiquitous Language
- 8. The model we want… • Helps us solve specific problems in our domain. • Is not necessarily “realistic”. • Forms the basis of a language. • Should remain current.
- 10. Expressing the Model • The model can be expressed through class diagrams, explanatory diagrams, sequence diagrams or whatever conveys the model. • But, the design document is not the model! The design document's purpose is to help communicate and explain the model. • The model is ultimately expressed in the code.
- 11. DDD is Agile and Iterative The problem with Big Design Up Front: • Models are distilled knowledge. • At the beginning of a project, the team is as ignorant as it will ever be. • Up Front Analysis Locks in Ignorance!
- 12. Big Design Up FrontBig Design Up Front
- 13. The DDD ProcessThe DDD Process
- 15. One Team, One Language, One ModelOne Team, One Language, One Model
- 16. A Complex DomainA Complex DomainA Complex DomainA Complex Domain
- 17. Bounded Context An operational definition of where a particular model is well-defined and applicable. (Typically a subsystem, or the work owned by a particular team). Subdomain Part of the domain, based on a particular conceptual decomposition of the domain. Breaking Down a Complex Domain
- 23. User Interface Responsible for presenting information to the user and interpreting user commands. Application This is a thin layer which coordinates the application activity. It does not contain business logic. It does not hold the state of the business objects. Domain This layer contains information about the domain. This is the heart of the business software. The state of business objects is held here. Persistence details delegated to the Infrastructure layer. Infrastructure This layer acts as a supporting library for all the other Layers. It provides communication between layers, implements persistence for business objects, contains supporting libraries for the user interface layer, etc. Layers
- 24. Model Expressed in Software • Entities • Value Objects • Aggregates • Services • Associations • Factories • Repositories • Modules • Context Mapping
- 25. Entities • Objects which have an identity which remains the same throughout the states of the software. • Must be distinguished from other similar objects having the same attributes. (e.g. Bank Account for Jim Smith) • Attributes of an entity can change. (Mutable) • Entities should have behavior. (Business Logic) • No persistence behavior!
- 26. Value Objects • Value Objects are the “things” within your model that have no uniqueness. • They are only equal to another Value Object if all their attributes match. • Value Objects are interchangeable. • Attributes of a Value Object cannot change, they must be replaced. (Immutable) • Examples: Money, Address (usually), DTO
- 27. Aggregates • An Aggregate is a cluster of Entities and Value objects. (Object Graph) Each aggregate is treated as one single unit. • Each Aggregate has one root entity know as the Aggregate Root. • The root identity is global, the identities of entities inside are local. • External objects may have references only to root. • Internal objects cannot be changed outside the Aggregate.
- 28. Aggregates
- 29. Associations • Impose a traversal direction. • Add a qualifier, reduce multiplicity. • Eliminate non essential associations.
- 30. Application “if the banking application can convert and export our transactions into a spreadsheet file... that export is an APPLICATION SERVICE” Domain “If a service were devised to make appropriate debits and credits for a found transfer, that capability would be a DOMAIN SERVICE” Infrastructure “a bank might have an application that sends an e-mail. The interface that encapsulates the email system is an INFRASTRUCTURE SERVICE” Services Reside in Multiple Layers
- 31. Domain Services • A Domain Service is Business Logic in the domain that are not a natural part of an Entity or Value Object. • Services usually manipulate multiple Entities and Value Objects. • Services are stateless! • A service has to be offered as an interface that is defined as a part of the model. Its parameters and results should be domain objects.
- 32. Factories • An object whose responsibility is the creation of other objects. • Create and manage complex domain objects. • Especially useful for creating aggregates.
- 33. Repositories • A Repository encapsulates domain objects persistence and retrieval. • Clean separation and one-way dependency between the domain and data mapping layers. • May encapsulate different fetching strategies, distributed caching, NoSQL, Web Service, etc. • Acts as a collection except with more elaborate querying capability. • One Repository per Aggregate!
- 34. Modules • Break up your domain to reduce complexity • High cohesion within module, loose coupling between modules. • Becomes part of the ubiquitous language • Helps with decoupling • Aids in extensibility
- 35. Context Mapping • Mapping the contact points and translations between bounded contexts.
- 36. Patterns for Context Mapping • Shared Kernel • Customer/Supplier • Conformist • Anti-corruption Layer • Separate Ways
- 37. Resources
- 38. These are not the same: • Subdomain – Decomposition of the domain. • Module – Decomposition of the model and associated software. • Aggregate – Decomposition of the run-time data. • Service – Decomposition of functionality. • Bounded Context – Linguistic boundary marking the applicability of distinct models.
- 39. Command Query Responsibility Segregation (CQRS)
- 40. The data that a client needs from the model is screen based and different than the domain model.
Editor's Notes
- #12: That is a pretty dense statement. Over the next few hours, we’ll try to define enough terms and explain enough of what we concretely do in order to unpack this statement.
- #21: Pegue o modelo de domínio de uma aplicação de e-commerce. Há muitos componentes diferentes que formam o grande sistema global. Algumas peças podem ser encontrados em qualquer sistema de e-commerce, mas alguns vão ser exclusivo para sua empresa. Estas peças irão definir o software e serão as razões fundamentais que você está construindo em vez de comprar.