how_does_ddd_work
-
Upload
tomas-maconko -
Category
Documents
-
view
112 -
download
0
Transcript of how_does_ddd_work
How does Domain-Driven Design work?
Tomaš [email protected]
What is it?“That’s just 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!”
What is it?“Domain-driven design (DDD) is an approach to software development for complex needs by connecting the implementation to an evolving model.”
What is complexity?•Business is the domain•Complexity is the domain (problem) itself•Domain consists of complex processes, workflows, rules etc. •Different specialists collaborate together to make business value
CAR BUSINESS DOMAIN
Domain areas
Core subdomain
Supporting subdomains
Core subdomain and supporting 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
Core subdomain
Lets look inside• Marketing• Sales• Billing• Production• Logistics• Operations• …
BOUNDED CONTEXTS
Bounded context•A pattern in Domain-Driven Design•A chunk of solution space•Helps dealing with large models•Ubiquitous language
Ubiquitous language
Ubiquitous language•Requires people in 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
Car (production): engine, wheels,
body, …
Car (billing): car parts expenses,
salaries
Car (marketing): photo, video, description, …
PRODUCTION
Value object•Does not have identity•Comparable by all its attributes•IMMUTABLE!•Allows to encapsulate business rules
Value object
Entity•A set of attributes and verbs•Has identity (engine ID number)•Cannot (logically) work without aggregate•Mutable
Entity
Aggregate and aggregate root•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
Aggregate
Aggregate root
Respository• Encapsulates aggregates persistence and retrieval• Persistence ignorance• Can be used as abstraction for different underlying
technologies (SQL, NoSQL, web-services, caching, etc.)• One repository per aggregate
Repository
INTEGRATION
How to combine stuff together?2. Stop pedal
pressed!
1. I listen for stop pedal
pressed
1. I listen for stop pedal
pressed3. I handle it
3. I handle it
4. Started
stopping
4. Stop lights turned
on
1. I listen for
acceleration pedal
pressed
Domain event•Messages in past 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)
THAT’S IT!
Pros• Involves team into 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
Cons•Requires team time and effort for analysis•Requires stronger skills on modeler side and OOP•Complicates small systems•Requires time to define UL DDD
So, what next?• CQRS• Event sourcing• Microservices