Download to read offline
Uploaded byTomaš Maconko
how_does_ddd_work
This document provides an overview of domain-driven design (DDD). It defines DDD as an approach that connects software implementation to an evolving domain model. It discusses examining the problem domain to identify subdomains and the core subdomain. It also covers concepts like bounded contexts, ubiquitous language, entities, value objects, aggregates, aggregate roots, and repositories. The document notes pros of DDD include involving teams in domain analysis, helping to understand and split the domain, and producing clean code. Cons include the time required for domain analysis and defining the ubiquitous language.
how_does_ddd_work
- 1. How does Domain-Driven Design work? TomašMaconko tomasmaconko@gmail.com
- 2. What is it? “That’sjust a rubbish theory!” “Its just another way to structure your code!” “Its hard to understand!” “It requires lots of useless coding!” “Nobody wants to use it!”
- 4. What is it? “Domain-drivendesign (DDD) is an approach to software development for complex needs by connecting the implementation to an evolving model.”
- 5. What is complexity? •Businessis the domain •Complexity is the domain (problem) itself •Domain consists of complex processes, workflows, rules etc. •Different specialists collaborate together to make business value
- 7. Domain areas Core subdomain Supportingsubdomains
- 8. Core subdomain andsupporting subdomains • DDD requires you to examine the business deeply • It enables you to split up the problem into smaller pieces (subdomains) to outline the core piece (core subdomain) • Allows you to pay attention to each piece separately (even to work in different teams) and concentrate mostly on the core
- 9.
- 10. Lets look inside •Marketing • Sales • Billing • Production • Logistics • Operations • …
- 12. Bounded context •A patternin Domain- Driven Design •A chunk of solution space •Helps dealing with large models •Ubiquitous language
- 13.
- 14. Ubiquitous language •Requires peoplein same bounded context using same terms (dictionary) •Same term is unambiguous for all team members (domain experts, developers, QA, etc.) •Defined and maintainable by whole team
- 15. Car (production): engine, wheels,body, … Car (billing): car parts expenses, salaries Car (marketing): photo, video, description, …
- 17. Value object •Does nothave identity •Comparable by all its attributes •IMMUTABLE! •Allows to encapsulate business rules
- 18.
- 19. Entity •A set ofattributes and verbs •Has identity (engine ID number) •Cannot (logically) work without aggregate •Mutable
- 20.
- 21. Aggregate and aggregateroot •Entity •Joins related entities and value objects •Encapsulates complex and state-dependent requirements in domain classes •It is highly recommended (required) to have single aggregate per transaction
- 22.
- 23.
- 24. Respository • Encapsulates aggregatespersistence and retrieval • Persistence ignorance • Can be used as abstraction for different underlying technologies (SQL, NoSQL, web-services, caching, etc.) • One repository per aggregate
- 25.
- 27. How to combinestuff together? 2. Stop pedal pressed! 1. I listen for stop pedal pressed 1. I listen for stop pedal pressed 3. I handle it 3. I handle it 4. Started stopping 4. Stop lights turned on 1. I listen for acceleration pedal pressed
- 28. Domain event •Messages inpast tense •Result of completed command •Integrates aggregates or bounded contexts with minimal coupling and dependencies •Reduces the number of changes in existing code •Improves responsiveness (asynchronous processing)
- 30. Pros • Involves teaminto domain analysis • Helps splitting and understanding the domain • Unambiguous terms • Changes the way developers think about solution • Strong domain model • Clean and maintainable code DDD Domain
- 31. Cons •Requires team timeand effort for analysis •Requires stronger skills on modeler side and OOP •Complicates small systems •Requires time to define UL DDD
- 32. So, what next? •CQRS • Event sourcing • Microservices