Domain Driven Design - GitHub Pageswouter-swierstra.github.io/MSO-2015/slides/slides-sogyo.pdf ·...
53
Transcript of Domain Driven Design - GitHub Pageswouter-swierstra.github.io/MSO-2015/slides/slides-sogyo.pdf ·...
Objectives
1. Show the usefullnes of DDD
2. Warn you about a two headed monster
3. Highlight two core concepts of DDD
2/27
Objectives
1. Show the usefullnes of DDD
2. Warn you about a two headed monster
3. Highlight two core concepts of DDD
2/27
Objectives
1. Show the usefullnes of DDD
2. Warn you about a two headed monster
3. Highlight two core concepts of DDD
2/27
ProblemsThreats for developing software systems in real life
Implicit knowledge
Implicit (business) knowledge is, if codified at all, often added tosoftware as an afterthought:
Only shows up as defects (I expected that..., doing so should....)
Arises later then needed in the development process, possiblyhiding key abstractions
Because they are implicit they are hard to validate: what iscorrect behaviour?
4/27
https://leanpub.com/software-architecture-for-developers/read
Domain Driven DesignWhat are the key concepts?
Key Concepts
Domain and model
Ubiquitous language
Bounded context
8/27
Key Concepts
Domain and model
Ubiquitous language
Bounded context
8/27
Key Concepts
Domain and model
Ubiquitous language
Bounded context
8/27
Two-headed monster?
Figure: http://muppet.wikia.com/wiki/Two-Headed_Monster
10/27
Part IIThe building blocksof a Model-Driven
Design
UbiquitousLanguage
Part IVStrategic Design
Ubiquitous language
Ubiquitous language
A language structured around the domain model that is used by allstakeholders to connect all the activities directly with software.
Grasping customer concepts and detecting inconsistencies
Shared language with domain expert
Business concepts become “first class citizens” of the code.
Multiple domains get their own language
Bridges gap between business, technology and other domains
12/27
Ubiquitous language
In short:
Unambigous
Embedded in code and daily vocabulary
Used by every single stakeholder
13/27
DDD PrimitivesThe building blocks of a Model-Driven Design
Primitives
Building blocks for DDD
Received most attention because they are in the first part ofthe book
Actually just implementation details
15/27
https://kenai.com/projects/chessgame/pages/%5B02%5D%5BDDD%5D
Primitives
Building blocks for DDD
Received most attention because they are in the books firstpart
Actually just implementation details
Not the essence of DDD
17/27
Most important primitive
Aggregate
Cluster of domain objects
Accessible via the root object
Provides a transactional boundary
Example: Car
Window
...
Engine
...
Wheel
Tire Axel Hubcap
18/27
Most important primitive
Aggregate
Cluster of domain objects
Accessible via the root object
Provides a transactional boundary
Example: Car
Window
...
Engine
...
Wheel
Tire Axel Hubcap
18/27
Strategic designBounded Context
Bounded Context
To deal with large models, DDD divides them in different,separated Bounded Contexts
Their relations are explicit since they can only occur atdomain boundaries
Integrate bounded context at the borders (using events)
In each individual bounded context, focus on that specificdomain and use an explicitly separated ubiquitous language.
20/27
Prevent monopolization!
Make sure that each domain gets their own context
22/27
Bounded Context
Localise the effects of various contexts within your domain
24/27
Wrapping up
Wrapping up
1 Show the usefullnes of DDD
Make the domain as explicit as you can
2 Warn you about a two headed monster
Strategic design: the actual essence of DDD
3 Highlight two core concepts of DDD
Bounded context and aggregate root: a killer combo
26/27
Wrapping up
1 Show the usefullnes of DDD
Make the domain as explicit as you can
2 Warn you about a two headed monster
Strategic design: the actual essence of DDD
3 Highlight two core concepts of DDD
Bounded context and aggregate root: a killer combo
26/27
Wrapping up
1 Show the usefullnes of DDD
Make the domain as explicit as you can
2 Warn you about a two headed monster
Strategic design: the actual essence of DDD
3 Highlight two core concepts of DDD
Bounded context and aggregate root: a killer combo
26/27
Questions?
27/27
Architectural patterns withDomain Driven Design
Architectural patterns: Microservices
Microservices
29/27
Architectural patterns: Microservices
Highly visible right now. Accelerated by culture and tooling aroundDevOps, Agile, Continuous Integration, Continuous Delivery etc.
30/27
http://martinfowler.com/articles/microservices.html
Architectural patterns: Microservices
Physically splitting up monoliths
Organized around business capabilities (which are boundedcontexts)
If certain rules are followed this pattern can be highly scalableand available.
Development of individual contexts is as loosely coupled as itcan be (separate languages, systems, ...)
32/27
Architectural patterns: Microservices
CQRS
33/27
Architectural patterns: CQRS
Based on Bertrand Meyer’s Command and Query Separation(CQS)
Methods either retrieve data (side effect free):Person.Move(newAddress)
Or change state (obviously has a side effect):Address address = Person.GetAddress()
34/27
Architectural patterns: CQRS
Command Query Separation (CQS):
separate reads and writes in their own actions
Command Query Responsibility Segregation (CQRS):
... and in their own classes
... and in their own modules
... and in their own deployables
... and in their own runtime process
... and in their own servers
... and in their own databases
35/27
http://blog.trifork.com/2010/01/27/cqrs-designing-domain-events/
Architectural patterns: CQRS
What happens?
Scaling of reads and writes
Different, physically separated representations of the samedata
Application level sharding (for example: geographic regions ofthe same applications)
Eventual Consistency
37/27
Architectural patterns: CQRS
What happens?
Scaling of reads and writes
Different, physically separated representations of the samedata
Application level sharding (for example: geographic regions ofthe same applications)
Eventual Consistency
37/27
Architectural patterns: Event Sourcing
Event Sourcing
38/27
Architectural patterns: Event Sourcing
What is an event? A description of something that happened at aspecific moment in time.
Past tense
Contains all relevant information about the “something”
It already happened, it cannot be ignored, deleted or mutated.
39/27
Architectural patterns: Event Sourcing
The trick is: expose the domain as an observable sequence ofevents and do this in pure business terms
MortgageRequestReceived
MortgageRequestApproved
MortgageClosed
MonthlyRepaymentReceived
ExtraRepaymentReceived
40/27
Architectural patterns: Event Sourcing
What is the current due ammount of a loan?
Most systems define state as leading: they store a value torepresent the answer. Event sourcing makes it a derivative: it iscalculated by applying events over time to a shared state.
To put it differently: it basically is a foldl of facts:state = ((((a+ b) + c) + d) + ...)
41/27
Architectural patterns: Event Sourcing
By deriving state from events you get a few things for free:
Following state through time
Changing the way you represent data but without losing any
Applying temporal queries on your data.
Canonical example of Greg Young: I as a Doctor want to findpatients for a clinical trial. I am looking for patients that werediagnosed with pancreatic cancer within the last 6 months.Within 1 week of diagnosis they were placed on treatment T1and were given the treatment more than 3 times but less than7 within a 3 week period. They then failed the treatment witha lab result that looks like R1. They were then placed on atreatment T2 within two weeks and failed with a lab resultthat looked like R2.
42/27
Architectural patterns: Event Sourcing
By deriving state from events you get a few things for free:
Following state through time
Changing the way you represent data but without losing any
Applying temporal queries on your data.
Canonical example of Greg Young: I as a Doctor want to findpatients for a clinical trial. I am looking for patients that werediagnosed with pancreatic cancer within the last 6 months.Within 1 week of diagnosis they were placed on treatment T1and were given the treatment more than 3 times but less than7 within a 3 week period. They then failed the treatment witha lab result that looks like R1. They were then placed on atreatment T2 within two weeks and failed with a lab resultthat looked like R2.
42/27
Architectural patterns: Actor model
Actor model
43/27
Architectural patterns: Actor model
See http://www.amazon.com/Reactive-Messaging-Patterns-Actor-Model/
dp/0133846830
44/27
