Download as PDF, PPTX
Uploaded byAsher Sterkin
Domain driven design: a gentle introduction
This document provides an overview of Domain-Driven Design (DDD) concepts including: - The common language shared between domain experts and software developers. - Using models to capture the semantics of the domain language. - Identifying multiple domain models with clear boundaries and mappings between them. - Nesting boundaries at different levels of granularity such as sub-domains, bounded contexts, and aggregates. - Key DDD patterns like entities, values, events, commands, and aggregates.
More Related Content
Similar to Domain driven design: a gentle introduction
Domain driven design: a gentle introduction
- 1. Domain-Driven Design A GentleIntroduction into Challenging Topic Asher Sterkin asher.sterkin@gmail.com Clean Code Meetup January 2, AppsFlyer
- 2. About DDD IL AsherSterkinVladik Khononov Erik Ashepa ● White belt circle: spread the word about DDD ● Black belt circle: apply DDD to real problems Feel free to reach out if you want to join any of them
- 3. About Myself ● Softwaretechnologist/architect ● Almost 40 years in the field ● Former VP Technology @ NDS and Distinguished Engineer @ Cisco ● Currently CTO @ IRKI ● C-level mentoring on software strategy ● Cross-discipline approach (connecting the dots): ○ (Strategic) Domain-Driven Design ○ Serverless Architecture ○ Cynefin ○ Wardley Maps ○ Lean Startup ○ Promise Theory ○ ...
- 4. ● Just anoverview of the main DDD concepts ● All examples are purely illustrative ● No architectural or technological recommendations ● All wording is mine, as well as mistakes Disclaimer
- 5. Domain-Driven Design isMore Relevant than Ever ● Software infrastructure is rapidly commoditized ● Focus on delivering business value “yesterday” ● AI, AR, VR, 3DP, IoT, Blockchain spiral complexity up ● Need a practical method to keep complexity under control ● So far DDD has an unsurpassed record in this area
- 6. Domain-Driven Design Acronym L M B N PronouncedLA-M-BA-N (invention is mine)
- 7. Domain-Driven Design ata Glance Language Model Boundaries Nesting
- 8. Language ● Common (ubiquitous)language for domain and software experts ● Vocabulary reflected directly in software ● Normally a subset of domain-specific jargon DDD is essentially a linguistic process
- 9. Model • Language elementshave meaning (semantics) • Semantics is captured in a form of formal model: – Object-Oriented – Statecharts – Functional – Relational – Graph – Mathematical – Neural Networks – … DDD is also a modeling process
- 10. Boundaries ● “One sizefits all” models are impractical ● G-d like models result in Big Ball of Mud ● DDD insists on identifying multiple models: ○ Coherent within their own boundaries ○ Mapped onto others where appropriate DDD is about maintaining boundaries for- and mappings between- models
- 11.
- 12. Example SWHR SWFN Employee, Salary,Bonus, ...
- 13. Nesting ● Boundaries existat different levels of granularity ● Within DDD approach the following levels of granularity are considered: ○ Conceptual boundaries (sub-domains) ○ Application and Domain Services ○ Bounded Context ○ Stateless vs Stateful Elements ○ Aggregate ○ Entity ○ Value ● It’s possible to stop at any level and still have some value ● Not all parts of the system will be designed equally well!
- 14.
- 15. Sub-domains (popular version) GenericServices Supporting Services Core Needs to be done, but no advantage Makes you money 3rd party products/services, no advantage
- 16. Example (my approach) GenericServices Supporting Services Core ... ... Green Invoice push down pull up Generic for any domain Common for group of domains Essense of my business Strategic Impact: build, buy, contribute
- 17. CDN Application vs DomainServices (oversimplified) users things robots UI devices Application Services Domain ServicesDDD is primarily focused on thisSome practitioners believe that applying DDD here would be an overkill, some others do not IoT Device Gateway API Gateway IoT Protocol Gateway API Gateway App Service Domain Service Domain Service App Cache App Service App Service Event Stream
- 18. Example Clients App ServicesDomain Services ? ? ?
- 19. Textbook Example: NetflixAPI App API App Services Domain API Domain API
- 20. Bounded Context Bounded Context DomainModel Ubiquitous Language Nouns, Adjectives, Imperative Verbs, Interrogative Verbs, Perfect Tense Verbs, Syntax, Grammar Entities, Values, Commands, Queries, Events, Aggregates, Repository, Computational Services, Factories, Anti-Corruption Layer, Saga Bounded Context Domain Model Ubiquitous Language context map ● Linguistic boundaries ● Reflect commitment to maintain strong cohesion inside and loose coupling outside ● Inside Bounded Context the model could evolve independently ● Defines a Minimal Meaningful scope with Maximum Acceptable Risk of not having semantic consistency across different parts of the system (not too much, not too little)
- 21.
- 22. Example (my systemat the moment) Bounded Context Front Office Bounded Context Back Office Bounded Context Product Design Green Invoice
- 23. Stateless vs Stateful Saga Stateless Computation StatefulObject Implements a multi-step workflow. Needs state to keep track of progress and run compensating transactions in the case of failure Stateful Objects introduced when managing State is a part of the Domain Service contract Performs computation which does not naturally fit into any stateful object. In particular could be a Factory for some Stateful Object with complex creation process
- 24.
- 25. Example (mine) Workflow Product Item Registration Stateless Computation Resize Picture ProductCatalog Pictures Product Types Colors
- 26. Strong Transaction Consistency +Invariant DDD Aggregate and Repository <<Aggregate Root>> Entity Entity Value Value Eventual Transaction Consistency aggregate storage store/retrieve requests --> command/query requests --> update/query method call --> ● Data integrity boundaries ● Reflects commitment to maintain strong transactional consistency inside and eventual consistency outside ● Inner parts are accessible only via Aggregate Root ● Inside Aggregate some form of invariant is maintained ● Aggregates of the same type are stored within Repository ● Defines a Minimal Meaningful transactional scope with Maximum Acceptable Risk level of not having immediate data consistency across different parts of the system (not too much, not too little) Command/query Request Processor Aggregate Repository Aggregate
- 27. DDD Entity, Value,Event, and Command <<Aggregate Root>> Entity Entity Value Value Puts boundaries around some identity, which has state and history <<Aggregate Root>> Entity Ref Value Many Aggregates are flat, but some have nested Entities Does not have identity or history. Encapsulates raw data types (e.g. Integer, String) to supply meaningful names from Ubiquitous Language (e.g. Street) including external references to other Aggregates Event Something interesting happened Command Way to send an update request to Aggregate
- 28.
- 29. Example (mine) Tariff Changed <<Aggregate Root>> ProductType Tariff Necklace Bracelet Earrings ... OperationBeadwork Clasp ... Currency NIS Change Tariff
- 30. Advanced Topics notCovered Here ● Strategic DDD Patterns ● Context Mapping ● Command-Query Request Segregation (CQRS) ● Event Sourcing (ES) ● Dealing with Legacy Systems ● Event Storming ● DDD and Microservices (Erik’s talk) ● Cloud-native and Serverless DDD (area of my research) ● DDD and Machine/Deep Learning ● DDD and IoT ● DDD and VR/AR ● ...
- 31.
- 32. DDD Video Library ●Eric Evans: Tackling Complexity in the Heart of Software ● Eric Evans: Good Design is Imperfect Design ● Eric Evans: DDD & Microservices: At Last, Some Boundaries! ● Eric Evans: Acknowledging CAP at the Root -- in the Domain Model ● Many, many more on YouTube and Vimeo ●
- 33. DDD Online ● EricEvans’ site: https://domainlanguage.com/ ● Domain-Driven Design on InfoQ: https://www.infoq.com/domain-driven-design ● Long curated list at https://github.com/heynickc/awesome-ddd ● Vladik’s Blog at http://vladikk.com/ ●
- 34.