![Page 1: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/1.jpg)
Workshop ldquoExperiencingDomain Driven Designrdquo
Summary
29-sept-2014
Workshop Experiencing Domain DrivenDesign
bull Cursusgever Mattias Verraes httpverraesnettalks
bull Workshop van drie dagen
bull Programma dag 1 Intro Systems thinking Event storming
bull Programma dag 2 (nav voting) Heuristics Boeken Context mapping
bull Programma dag 3 Event sourcing CQRS Event store Model storming
2
Domain Driven Design
3
Domain Driven Design Summarybull Summary Domain Driven Design Quickly
4
DDDbull Supple design
bull Declarative design
bull Refactoring
bull Bounded contexts
bull Distillation
bull Large-scale structure
bull Modelling whirlpool
bull Model storming
5
Event stormingbull Alberto Brandolini (link here)
bull Important events for the
business
bull Events ==gt Past tense and in the
Ubiquitious language
bull No consensus first better to have
alternatives
6
7
1) Find Domain Events
8
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
9
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
10
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
bull Expressed in Ubiquitous language
11
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
bull Expressed in Ubiquitous language
NO technical events like Network is down Transaction has failed
12
13
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
14
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
15
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
16
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
17
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
bull Possible sources human time process
18
19
3) Discover Bounded Contextsbull Explicit boundary between domain models
20
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
21
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
bull Example Fleet Management Scheduling
22
23
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
24
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
bull Example An already cancelled reservation cannot be cancelled anymore
25
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 2: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/2.jpg)
Workshop Experiencing Domain DrivenDesign
bull Cursusgever Mattias Verraes httpverraesnettalks
bull Workshop van drie dagen
bull Programma dag 1 Intro Systems thinking Event storming
bull Programma dag 2 (nav voting) Heuristics Boeken Context mapping
bull Programma dag 3 Event sourcing CQRS Event store Model storming
2
Domain Driven Design
3
Domain Driven Design Summarybull Summary Domain Driven Design Quickly
4
DDDbull Supple design
bull Declarative design
bull Refactoring
bull Bounded contexts
bull Distillation
bull Large-scale structure
bull Modelling whirlpool
bull Model storming
5
Event stormingbull Alberto Brandolini (link here)
bull Important events for the
business
bull Events ==gt Past tense and in the
Ubiquitious language
bull No consensus first better to have
alternatives
6
7
1) Find Domain Events
8
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
9
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
10
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
bull Expressed in Ubiquitous language
11
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
bull Expressed in Ubiquitous language
NO technical events like Network is down Transaction has failed
12
13
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
14
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
15
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
16
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
17
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
bull Possible sources human time process
18
19
3) Discover Bounded Contextsbull Explicit boundary between domain models
20
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
21
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
bull Example Fleet Management Scheduling
22
23
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
24
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
bull Example An already cancelled reservation cannot be cancelled anymore
25
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 3: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/3.jpg)
Domain Driven Design
3
Domain Driven Design Summarybull Summary Domain Driven Design Quickly
4
DDDbull Supple design
bull Declarative design
bull Refactoring
bull Bounded contexts
bull Distillation
bull Large-scale structure
bull Modelling whirlpool
bull Model storming
5
Event stormingbull Alberto Brandolini (link here)
bull Important events for the
business
bull Events ==gt Past tense and in the
Ubiquitious language
bull No consensus first better to have
alternatives
6
7
1) Find Domain Events
8
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
9
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
10
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
bull Expressed in Ubiquitous language
11
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
bull Expressed in Ubiquitous language
NO technical events like Network is down Transaction has failed
12
13
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
14
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
15
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
16
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
17
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
bull Possible sources human time process
18
19
3) Discover Bounded Contextsbull Explicit boundary between domain models
20
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
21
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
bull Example Fleet Management Scheduling
22
23
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
24
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
bull Example An already cancelled reservation cannot be cancelled anymore
25
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 4: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/4.jpg)
Domain Driven Design Summarybull Summary Domain Driven Design Quickly
4
DDDbull Supple design
bull Declarative design
bull Refactoring
bull Bounded contexts
bull Distillation
bull Large-scale structure
bull Modelling whirlpool
bull Model storming
5
Event stormingbull Alberto Brandolini (link here)
bull Important events for the
business
bull Events ==gt Past tense and in the
Ubiquitious language
bull No consensus first better to have
alternatives
6
7
1) Find Domain Events
8
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
9
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
10
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
bull Expressed in Ubiquitous language
11
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
bull Expressed in Ubiquitous language
NO technical events like Network is down Transaction has failed
12
13
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
14
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
15
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
16
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
17
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
bull Possible sources human time process
18
19
3) Discover Bounded Contextsbull Explicit boundary between domain models
20
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
21
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
bull Example Fleet Management Scheduling
22
23
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
24
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
bull Example An already cancelled reservation cannot be cancelled anymore
25
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 5: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/5.jpg)
DDDbull Supple design
bull Declarative design
bull Refactoring
bull Bounded contexts
bull Distillation
bull Large-scale structure
bull Modelling whirlpool
bull Model storming
5
Event stormingbull Alberto Brandolini (link here)
bull Important events for the
business
bull Events ==gt Past tense and in the
Ubiquitious language
bull No consensus first better to have
alternatives
6
7
1) Find Domain Events
8
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
9
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
10
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
bull Expressed in Ubiquitous language
11
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
bull Expressed in Ubiquitous language
NO technical events like Network is down Transaction has failed
12
13
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
14
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
15
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
16
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
17
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
bull Possible sources human time process
18
19
3) Discover Bounded Contextsbull Explicit boundary between domain models
20
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
21
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
bull Example Fleet Management Scheduling
22
23
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
24
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
bull Example An already cancelled reservation cannot be cancelled anymore
25
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 6: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/6.jpg)
Event stormingbull Alberto Brandolini (link here)
bull Important events for the
business
bull Events ==gt Past tense and in the
Ubiquitious language
bull No consensus first better to have
alternatives
6
7
1) Find Domain Events
8
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
9
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
10
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
bull Expressed in Ubiquitous language
11
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
bull Expressed in Ubiquitous language
NO technical events like Network is down Transaction has failed
12
13
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
14
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
15
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
16
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
17
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
bull Possible sources human time process
18
19
3) Discover Bounded Contextsbull Explicit boundary between domain models
20
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
21
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
bull Example Fleet Management Scheduling
22
23
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
24
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
bull Example An already cancelled reservation cannot be cancelled anymore
25
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 7: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/7.jpg)
7
1) Find Domain Events
8
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
9
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
10
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
bull Expressed in Ubiquitous language
11
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
bull Expressed in Ubiquitous language
NO technical events like Network is down Transaction has failed
12
13
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
14
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
15
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
16
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
17
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
bull Possible sources human time process
18
19
3) Discover Bounded Contextsbull Explicit boundary between domain models
20
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
21
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
bull Example Fleet Management Scheduling
22
23
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
24
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
bull Example An already cancelled reservation cannot be cancelled anymore
25
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 8: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/8.jpg)
1) Find Domain Events
8
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
9
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
10
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
bull Expressed in Ubiquitous language
11
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
bull Expressed in Ubiquitous language
NO technical events like Network is down Transaction has failed
12
13
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
14
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
15
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
16
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
17
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
bull Possible sources human time process
18
19
3) Discover Bounded Contextsbull Explicit boundary between domain models
20
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
21
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
bull Example Fleet Management Scheduling
22
23
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
24
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
bull Example An already cancelled reservation cannot be cancelled anymore
25
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 9: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/9.jpg)
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
9
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
10
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
bull Expressed in Ubiquitous language
11
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
bull Expressed in Ubiquitous language
NO technical events like Network is down Transaction has failed
12
13
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
14
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
15
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
16
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
17
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
bull Possible sources human time process
18
19
3) Discover Bounded Contextsbull Explicit boundary between domain models
20
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
21
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
bull Example Fleet Management Scheduling
22
23
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
24
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
bull Example An already cancelled reservation cannot be cancelled anymore
25
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 10: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/10.jpg)
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
10
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
bull Expressed in Ubiquitous language
11
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
bull Expressed in Ubiquitous language
NO technical events like Network is down Transaction has failed
12
13
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
14
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
15
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
16
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
17
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
bull Possible sources human time process
18
19
3) Discover Bounded Contextsbull Explicit boundary between domain models
20
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
21
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
bull Example Fleet Management Scheduling
22
23
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
24
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
bull Example An already cancelled reservation cannot be cancelled anymore
25
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 11: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/11.jpg)
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
bull Expressed in Ubiquitous language
11
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
bull Expressed in Ubiquitous language
NO technical events like Network is down Transaction has failed
12
13
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
14
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
15
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
16
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
17
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
bull Possible sources human time process
18
19
3) Discover Bounded Contextsbull Explicit boundary between domain models
20
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
21
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
bull Example Fleet Management Scheduling
22
23
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
24
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
bull Example An already cancelled reservation cannot be cancelled anymore
25
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 12: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/12.jpg)
1) Find Domain Eventsbull Happened in the past (expressed in past form A car was rented
Customer has subscribed)
bull Interest the business
bull Expressed in Ubiquitous language
NO technical events like Network is down Transaction has failed
12
13
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
14
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
15
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
16
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
17
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
bull Possible sources human time process
18
19
3) Discover Bounded Contextsbull Explicit boundary between domain models
20
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
21
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
bull Example Fleet Management Scheduling
22
23
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
24
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
bull Example An already cancelled reservation cannot be cancelled anymore
25
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 13: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/13.jpg)
13
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
14
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
15
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
16
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
17
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
bull Possible sources human time process
18
19
3) Discover Bounded Contextsbull Explicit boundary between domain models
20
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
21
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
bull Example Fleet Management Scheduling
22
23
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
24
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
bull Example An already cancelled reservation cannot be cancelled anymore
25
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 14: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/14.jpg)
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
14
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
15
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
16
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
17
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
bull Possible sources human time process
18
19
3) Discover Bounded Contextsbull Explicit boundary between domain models
20
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
21
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
bull Example Fleet Management Scheduling
22
23
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
24
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
bull Example An already cancelled reservation cannot be cancelled anymore
25
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 15: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/15.jpg)
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
15
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
16
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
17
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
bull Possible sources human time process
18
19
3) Discover Bounded Contextsbull Explicit boundary between domain models
20
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
21
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
bull Example Fleet Management Scheduling
22
23
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
24
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
bull Example An already cancelled reservation cannot be cancelled anymore
25
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 16: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/16.jpg)
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
16
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
17
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
bull Possible sources human time process
18
19
3) Discover Bounded Contextsbull Explicit boundary between domain models
20
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
21
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
bull Example Fleet Management Scheduling
22
23
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
24
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
bull Example An already cancelled reservation cannot be cancelled anymore
25
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 17: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/17.jpg)
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
17
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
bull Possible sources human time process
18
19
3) Discover Bounded Contextsbull Explicit boundary between domain models
20
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
21
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
bull Example Fleet Management Scheduling
22
23
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
24
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
bull Example An already cancelled reservation cannot be cancelled anymore
25
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 18: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/18.jpg)
2) Find Commandsbull Expressed in imperative phrase (Rent a car Subscribe)
bull They express intentcause for the business
bull They can fail
bull Multiple outcomes (including exceptions)
bull Possible sources human time process
18
19
3) Discover Bounded Contextsbull Explicit boundary between domain models
20
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
21
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
bull Example Fleet Management Scheduling
22
23
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
24
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
bull Example An already cancelled reservation cannot be cancelled anymore
25
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 19: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/19.jpg)
19
3) Discover Bounded Contextsbull Explicit boundary between domain models
20
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
21
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
bull Example Fleet Management Scheduling
22
23
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
24
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
bull Example An already cancelled reservation cannot be cancelled anymore
25
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 20: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/20.jpg)
3) Discover Bounded Contextsbull Explicit boundary between domain models
20
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
21
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
bull Example Fleet Management Scheduling
22
23
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
24
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
bull Example An already cancelled reservation cannot be cancelled anymore
25
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 21: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/21.jpg)
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
21
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
bull Example Fleet Management Scheduling
22
23
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
24
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
bull Example An already cancelled reservation cannot be cancelled anymore
25
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 22: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/22.jpg)
3) Discover Bounded Contextsbull Explicit boundary between domain models
bull Each context has its unique ubiquitious language
bull Example Fleet Management Scheduling
22
23
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
24
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
bull Example An already cancelled reservation cannot be cancelled anymore
25
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 23: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/23.jpg)
23
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
24
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
bull Example An already cancelled reservation cannot be cancelled anymore
25
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 24: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/24.jpg)
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
24
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
bull Example An already cancelled reservation cannot be cancelled anymore
25
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 25: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/25.jpg)
4) Find Business rules decisionsbull Put them on the map to make the different scenarios explicit
bull Example An already cancelled reservation cannot be cancelled anymore
25
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 26: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/26.jpg)
5) Group events that influence decision
26
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 27: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/27.jpg)
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
27
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 28: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/28.jpg)
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
28
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 29: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/29.jpg)
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
29
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 30: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/30.jpg)
6) Discover amp experiment with aggregateboundaries
bull Aggregate is a group of objects that work together and are treated as a
unit
bull Provide a specific functionality
bull Transactional
bull Cohesive
30
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 31: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/31.jpg)
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions
31
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 32: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/32.jpg)
HeuristicsHeuristics are different approaches we want to confront with while
building our models so that we can push our mind to influence our
design in different directions All those heuristics lead us to try different
models and throw them away at each time until we are happy with our
model
32
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 33: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/33.jpg)
Heuristics 15bull Stable (static data) vs Volatile (changing data)
33
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 34: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/34.jpg)
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
34
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 35: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/35.jpg)
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
35
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 36: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/36.jpg)
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
36
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 37: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/37.jpg)
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
37
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 38: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/38.jpg)
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
38
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 39: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/39.jpg)
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
39
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 40: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/40.jpg)
Heuristics 15bull Stable (static data) vs Volatile (changing data)
bull Type (hierarchy of objects) vs Properties (of an object)
bull Actor vs Roles
bull Change together vs change separately
bull Different lifecycle dependencies
bull Immutable vs Mutable
bull Immutability within a context only
bull Retroactive Business rules
40
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 41: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/41.jpg)
Heuristics 25bull Cohesive vs Decoupled
41
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 42: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/42.jpg)
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
42
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 43: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/43.jpg)
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
43
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 44: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/44.jpg)
Heuristics 25bull Cohesive vs Decoupled
bull Afferent coupling (things that are coupled to me) vs Efferent coupling
(things that I couple to) Noun lt Sentences lt Phrases
bull Follow the money
bull Use personas
44
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 45: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/45.jpg)
Heuristics 353 archetypes we find in almost every software
45
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 46: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/46.jpg)
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
46
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 47: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/47.jpg)
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
47
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 48: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/48.jpg)
Heuristics 353 archetypes we find in almost every software
bull Collaborative construction
bull Execution
bull Business intelligence tracking monitoring
48
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 49: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/49.jpg)
Heuristics 45bull Consistency
49
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 50: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/50.jpg)
Heuristics 45bull Consistency
bull Same rules but different semantics
50
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 51: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/51.jpg)
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
51
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 52: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/52.jpg)
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
52
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 53: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/53.jpg)
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
53
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 54: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/54.jpg)
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
54
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 55: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/55.jpg)
Heuristics 45bull Consistency
bull Same rules but different semantics
bull Warnings vs errors
bull Synchronous (ordered) vs Asynchronous (unordered) [on a business point
of view not a technical one] Happy path vs divergent path
bull Responsibility Layers (see Evans)
bull Atomicity Transactionality
bull Risks
55
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 56: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/56.jpg)
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
56
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 57: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/57.jpg)
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
57
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 58: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/58.jpg)
Heuristics 55bull Strictness (do we restrict user) vs Allow the user to abuse the system and
monitor the abuse
bull Start from the end
bull Let the human do it
58
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 59: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/59.jpg)
Brownfield DDDStart by drawing the Current Model and the Desired Model Make a small
step toward the Desired Model Throw away both drawing models
regularly while in the process of leading the current model to the desired
model so that desired model also evolved with the maturity of our
understanding
59
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 60: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/60.jpg)
Brownfield DDDHave a wall were people write identified Technical Debt Each time
someone stumble upon the same debt put a dot in front of it This helps
us identify the most critical debt
60
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 61: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/61.jpg)
Context MappingHow do our different contexts communicate
61
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 62: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/62.jpg)
Context MappingHow do our different contexts communicate
Relationships fall into repeatable patterns
62
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 63: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/63.jpg)
Context Mapping 12bull Shared kernel
63
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 64: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/64.jpg)
Context Mapping 12bull Shared kernel
bull Customer supplier
64
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 65: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/65.jpg)
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
65
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 66: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/66.jpg)
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
66
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 67: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/67.jpg)
Context Mapping 12bull Shared kernel
bull Customer supplier
bull Published language (language from a long running domain)
bull Partnership
bull Separate ways (rebuild the stuff you need)
67
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 68: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/68.jpg)
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
68
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 69: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/69.jpg)
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
69
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 70: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/70.jpg)
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
70
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 71: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/71.jpg)
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
71
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 72: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/72.jpg)
Context Mapping 22bull Anticorruption layer (translate from upstream to downstream model)
bull Conformist (mimic upstream model)
bull Open Host Service (public 3rd party api we cannot influence (google
maps))
bull Big Ball of Mud
bull Put yourself on the map
72
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 73: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/73.jpg)
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
73
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 74: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/74.jpg)
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
74
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 75: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/75.jpg)
CQRSCQRS challenge the assumption that reading and writing are supposed to
share the same abstractions amp models amp databases amp applications
So in short Split Write Model and Read Models
The presentation httpsspeakerdeckcommathiasverraesfighting-
bottlenecks-with-cqrs
75
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 76: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/76.jpg)
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
76
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 77: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/77.jpg)
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
77
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 78: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/78.jpg)
Event SourcingUsing objects history to reconstitute its state The history is expressed
as a series of Domain events
The aggregate records events and protect invariant but does not expose
the state Aggregate is the write model State is exposed by projector
(one of the read models)
The presentation and some code at
httpsspeakerdeckcommathiasverraespractical-event-sourcing
78
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 79: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/79.jpg)
Event SourcingDo not put invariant in the apply method because you couldnrsquot restore
the aggregate anymore if invariant change It is then possible to have
aggregate that do not comply with new invariants and it is a business
decision to know what to do with these
79
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 80: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/80.jpg)
Event SourcingProjectors should be easy to write Donrsquot use an ORM here since they will
slow the process down
80
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 81: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/81.jpg)
Testing the write model is like
bull Given previous events
bull When command
bull Then expected new events or expected exception
Testing projector read model is like
bull Given previous events
bull Then expected states
81
82
![Page 82: Domain Driven Design” Workshop “Experiencing · Domain Driven Design” Summary 29-sept-2014. Workshop Experiencing Domain Driven Design • Cu r s u s g eve r : M a t t i a s](https://reader034.vdocuments.net/reader034/viewer/2022051812/602c0ecaf73c8f078019a63a/html5/thumbnails/82.jpg)
82