Slide 1
Slide 1 text
From EventStorming
to CoDDDing
Slide 2
Slide 2 text
2
Strategic Technology Consultants -
Agile Technical Coaches -
Domain-Driven Design - Continuous
Delivery - EventStorming - Example
Mapping
@kenny_baas
baasie.com
@joaoasrosa
joaorosa.io
Slide 3
Slide 3 text
No content
Slide 4
Slide 4 text
4
@kenny_baas @joaoasrosa
Slide 5
Slide 5 text
No content
Slide 6
Slide 6 text
No content
Slide 7
Slide 7 text
7
The fundamental horror of this anti-pattern
is that it's so contrary to the basic idea
of object-oriented designing;
which is to combine
data and process together.
- Martin Fowler
@kenny_baas @joaoasrosa
Slide 8
Slide 8 text
8
What's worse, many people think that
anemic objects are real objects,
and thus completely miss the point of what
object-oriented design is all about.
- Martin Fowler
@kenny_baas @joaoasrosa
Slide 9
Slide 9 text
9
@kenny_baas @joaoasrosa
Slide 10
Slide 10 text
10
@kenny_baas @joaoasrosa
Slide 11
Slide 11 text
We all know or should know that language is fluid, liquid, subject to the
whims of the people. Language evolves, as it should. Because language
changes to accommodate new users, the older users resist and complain.
http://tednellen.blogspot.com/2013/04/language-is-fluid.html
Slide 12
Slide 12 text
No content
Slide 13
Slide 13 text
No content
Slide 14
Slide 14 text
No content
Slide 15
Slide 15 text
No content
Slide 16
Slide 16 text
16
@kenny_baas @joaoasrosa
Slide 17
Slide 17 text
17
Confirmation Bias
@kenny_baas @joaoasrosa
Slide 18
Slide 18 text
18
@kenny_baas @joaoasrosa
Slide 19
Slide 19 text
19
It is not the domain experts knowledge
that goes to production, it is the
assumption of the developers
that goes to production
- Alberto Brandolini
@kenny_baas @joaoasrosa
Slide 20
Slide 20 text
20
@kenny_baas @joaoasrosa
Slide 21
Slide 21 text
21
The greatest obstacle to discovery is not ignorance -
it is the illusion of knowledge.
- Daniel J. Boorstin
@kenny_baas @joaoasrosa
Slide 22
Slide 22 text
22
@kenny_baas @joaoasrosa
Slide 23
Slide 23 text
No content
Slide 24
Slide 24 text
No content
Slide 25
Slide 25 text
25
Big Picture
Process Design
and Modelling
Software
Modelling
@kenny_baas @joaoasrosa
Slide 26
Slide 26 text
26
@kenny_baas @joaoasrosa
Slide 27
Slide 27 text
27
@kenny_baas @joaoasrosa
Slide 28
Slide 28 text
28
@kenny_baas @joaoasrosa
Slide 29
Slide 29 text
No content
Slide 30
Slide 30 text
No content
Slide 31
Slide 31 text
31
Source: https://medium.freecodecamp.org/coding-explained-in-25-profound-comics-8847ea03819c
@kenny_baas @joaoasrosa
Slide 32
Slide 32 text
32
Source: https://nl.pinterest.com/pin/550846598149452758/
@kenny_baas @joaoasrosa
Slide 33
Slide 33 text
33
Source:https://www.dw.com/en/maligned-ronaldo-statue-replaced-at-madeira-airport/a-44279114
@kenny_baas @joaoasrosa
Slide 34
Slide 34 text
34
Solution Space
Our world as we designed it
Bounded Context
Software Architecture
Linked to the business
Problem Space
Our world as we perceive it
(Sub)Domains
Business Architecture
Independent of Software
@kenny_baas @joaoasrosa
Slide 35
Slide 35 text
35
@kenny_baas @joaoasrosa
Slide 36
Slide 36 text
36
A model is a simplified representation of a thing
or phenomenon that intentionally emphasizes
certain aspects while ignoring others.
Abstraction with a specific use in mind.
@kenny_baas @joaoasrosa
Slide 37
Slide 37 text
37
@kenny_baas @joaoasrosa
Slide 38
Slide 38 text
38
@kenny_baas @joaoasrosa
https://blog.ncrunch.net/post/london-tdd-vs-detroit-tdd.aspx
Slide 39
Slide 39 text
No content
Slide 40
Slide 40 text
40
Source: https://nl.pinterest.com/pin/550846598149452758/
@kenny_baas @joaoasrosa
1. Write a coarse-grain test
a. Outside-in testing
2. Start with entrypoint of our model
3. Design-by-Coding
4. Assess if the models can easily
evolve to support other features
Slide 41
Slide 41 text
41
@kenny_baas @joaoasrosa
Slide 42
Slide 42 text
42
1. Protects business invariants
2. Design them small
3. Reference other by ID only
4. Update other using eventual
consistency
@kenny_baas @joaoasrosa
Slide 43
Slide 43 text
43
@kenny_baas @joaoasrosa
Source: https://unsplash.com/photos/eYZpTMc7hno
Domain logic that doesn’t belong to a
- Entity
- Value Object
Significant process or transformation that
concerns the domain logic
Isolate in a standalone interface
declared as a service
Part of the ubiquitous language
Slide 44
Slide 44 text
44
@kenny_baas @joaoasrosa
Slide 45
Slide 45 text
45
Source: http://www.mamuz.de/article/from-big-ball-of-mud-to-emergent-design/0Pw682Kxk
@kenny_baas @joaoasrosa
Slide 46
Slide 46 text
No content
Slide 47
Slide 47 text
47
Source: http://www.mamuz.de/article/from-big-ball-of-mud-to-emergent-design/0Pw682Kxk
@kenny_baas @joaoasrosa
1. Visualise
a. Business information flow
b. Behaviour of the system
2. Protect domain logic with tests
a. Inside-out
b. Outside-in
3. Experiment models to fit the
behaviour
a. Ubiquitous language will
emerge
4. Protect models with Bounded
Contexts
Slide 48
Slide 48 text
48
@kenny_baas @joaoasrosa
Slide 49
Slide 49 text
49
Software Development is
a learning process, working code is a
side effect.
- Alberto Brandolini
@kenny_baas @joaoasrosa
Slide 50
Slide 50 text
50
Try at least to find three models,
even if you think you already found
the “right model”
@kenny_baas @joaoasrosa
Slide 51
Slide 51 text
51
Serious software development is
the practice of symmathesy.
“Sym” = together, “mathesy” = learning.
- Jessica Kerr
@kenny_baas @joaoasrosa
Slide 52
Slide 52 text
#CatTax