Domain driven design
Download as PPTX, PDF1 like1,203 views
The document discusses domain-driven design (DDD) as a method to manage complexity in software development, emphasizing the importance of adaptability to change. It outlines key concepts such as bounded contexts, domain modeling, and various building blocks like entities, value objects, and domain events. The document also highlights advantages of DDD in complex and rapidly evolving business domains, while noting potential challenges such as integration complexity and the difficulty of domain modeling.
Domain driven design
- 2. https://nl.linkedin.com/in/iefcuynen @iefcuynen Ief Cuynen Domain Driven Design Tackling Complexity in the Heart of Software https://nl.linkedin.com/in/
- 3. It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change - Charles Darwin
- 4. Big Ball Of Mud
- 6. Domain & subdomains Yep, same picture
- 7. Bounded contexts Still the same
- 8. Context Maps: high level integration overview Types • Partnership • Shared Kernel • Customer-Supplier • Conformist • Anticorruption Layer • Published Language • Separate Ways • Big Ball Of Mud
- 9. Old school domain modeling airCraft.setRoute(newRoute) airCraft.go() Technical methods Separate Lingo • Business • Architecture • Developer • Code
- 10. Domain driven Modeling Ubiquitous language business = architecture = developer = code Business methods flightplan.assignFlightRoute(route) flight.takeOff()
- 11. Domain model – building blocks Entities Have an unique identity Continuous change over time Built up from value objects E.g Customer Value objects Objects that matter only as the combinations of their attributes No identity Immutable E.g. money, address
- 12. Domain model – building blocks Domain Services Connects to another remote domain model for interaction E.g. FlighplanFinder Aggregates Cluster of domain objects that can be treated as a single unit. E.g. Invoice & invoice lines Domain Events Business events fired after change of aggregate
- 14. CQRS Command Query Responsibility Segregation
- 15. Command and Query models Command Domain model Publishes busines events Query Built using domain events Best fit for each specific goal GUI Data mining Reporting Command Model X Command Model Y Query Model A Query Model B
- 16. Event sourcing Store the domain events in an event store Perfect match with CQRS Events can be replayed to build new query models Rebuild existing query models
- 17. DDD excels in Complex business domains Fast changing busines domains Scalable applications Asynchronous communication Micro services (= bounded context) Push and pull Caching Failure proof applications
- 18. DDD caveats Domain modeling is hard Can be expensive Complex integration Eventual consistency
Editor's Notes
- #5: Initial a simple model will suffice the business needs but without care and consideration it quickly turns in a big ball of mud Hard to maintain Hard to adapt
- #6: Domain = Problem space that needs to be solved Can be the business of the entire organisation or a subset Subdomain = Different business domains making up the entire domain Invoicing Stock Orders Inventory Core domain = sub domain where the most business value is gained. Differentiator in the market 20% of the total business value, 5% of the code, 80% of the effort (Eric Evans) Supporting subdomain Essential to business but not core Generic subdomain Non core subdomain E.g. invoicing Vendor package / outsource Bounded context Explicit boundary for a domain model
- #7: Domain = Problem space that needs to be solved Can be the business of the entire organisation or a subset Subdomain = Different business domains making up the entire domain Invoicing Stock Orders Inventory Core domain = sub domain where the most business value is gained. Differentiator in the market 20% of the total business value, 5% of the code, 80% of the effort (Eric Evans) Supporting subdomain Essential to business but not core Generic subdomain Non core subdomain E.g. invoicing Vendor package / outsource Bounded context Explicit boundary for a domain model
- #8: Domain = Problem space that needs to be solved Can be the business of the entire organisation or a subset Subdomain = Different business domains making up the entire domain Invoicing Stock Orders Inventory Core domain = sub domain where the most business value is gained. Differentiator in the market 20% of the total business value, 5% of the code, 80% of the effort (Eric Evans) Supporting subdomain Essential to business but not core Generic subdomain Non core subdomain E.g. invoicing Vendor package / outsource Bounded context Explicit boundary for a domain model
- #9: Context map = visual representation of Bounded contexts and their relationships Upstream = An upstream bounded context have an impact on a downstream bounded contexts Downstream = A downstream bounded context is impacted by upstream bounded contexts Relationships Partnership : 2 contexts succeed or fail together (released on same time) Shared Kernel : Intimate dependency between 2 or more bounded context by sharing a common bounded context Customer-Supplier: 2 bounded contexts in an upstream / downstream relationship where the success of the upstream is also dependent of the downstream bounded context Conformist: 2 bounded contexts in an upstream / downstream relationship where the downstream bounded context has no voice or impact whatsoever on the upstream bounded context Anticorruption Layer: When the downstream bounded context implements an isolation layer, to provide functionality of the upstream bounded context in terms of the downstream domain model E.g. Used to integrate legacy systems Open Host Service: Defines a protocol that gives access to the bounded context as a set of services E.g. REST services Published language: Well documented shared language that can express the necessary domain information as a common medium of communication E.g. Events Big Ball Of Mud Mixed models and inconsistent boundaries
- #10: Ubiquitous language Business lingo = architecture lingo = developer lingo = code A term is unique within a domain model but can have a completely different meaning in another domain model E.g. product as in a ‘scrum domain’ vs product in a ‘webshop domain’ Anemic domain model No behavior in the domain model All logic in application / infrastructure layers Small object graph Complex domain models bound to fail
- #11: Ubiquitous language Business lingo = architecture lingo = developer lingo = code A term is unique within a domain model but can have a completely different meaning in another domain model E.g. product as in a ‘scrum domain’ vs product in a ‘webshop domain’ Anemic domain model No behavior in the domain model All logic in application / infrastructure layers Small object graph Complex domain models bound to fail
- #14: Layered Architecture User Interface Layer Accepts User Commands and presents information back to the user Application Layer Managed transactions, translates DTOs, coordinates application activities, creates and accesses domain objects Domain Layer Contains the state and behavior of the domain Infrastructure Layer Supports all the other layers, includes repositories, adapters, frameworks Hexagonal Architecture promotes the separation of concerns through layers of responsibility Higher level of abstraction