How to design a ... calendar?
Sebastian Gebski - May 2019
DDD - the lost chapters
What is it about?
#design #modeling #domain #pragmatism #abstractions #heuristics #complexity #promises
#systemsthinking
Opinions are like assholes.
Everybody's got one.
Moar spice!
>> Books like "DDD in .NET" are a misunderstanding!
>> 99% of you should never eventsource!
>> It doesn't matter how your register command handlers. It's a distraction!
>> Time spent on hexagons, "cleaning" architectures, application VS domain services - it's a pure waste!
Trying to
re-write evangelion?
DDD is an ubiquitous language for people modeling domain(s).
Nah, just a bunch of heuristics
Shhh, what's a heuristic?
Heuristics are the strategies derived from previous experiences with similar problems
Heuristic is any approach to problem solving or self-discovery that employs a practical method, not guaranteed to be optimal, perfect, logical, or rational, but instead sufficient for reaching an immediate goal.
... and dispelling some myths
>> abstraction
>> concern -> capability
>> contract (promise)
>> cohesion
>> consistency scope
>> accumulator
>> pivot abstraction
>> side effect
>> inventory
>> forest of data
>> domain invariant
Who am I?
Geek, agilista, blogger, codefella, serial reader.
In the daylight: I lead software delivery.
#lean #kaizen #elixir #webdev #dotnet
Sebastian Gebski, CTO @ Shedul/Fresha
@liveweird - https://no-kill-switch.ghost.io
1. greatest (real) benefit
2. structure
4. functionality
3. information
6. hate
5. ownership over data
Our journey
We're like Uber
except we're not
>> B2B + B2C
>> *REAL* product
>> we're owners
>> no deps
>> 4 years
This is a calendar.
What's really good in DDD?
>> Ubiquitous Language
>> Code <-> Model <-> Domain parallelism
>> Bounded Contexts (+ctx mapping)
>> Functionality ownership over the data
>> Transactional boundaries
>> Domain Events
...
>> That's ALL (OMG, HERESY!)
True benefit of DDD
My kung-fu
is better than your kung-fu
How to measure
whether we're tackling complexity well?
Cynefin framework
where should we be aiming?
In "Complicated" quadrant
can the complexity grow
without local "knots"?
We need better
means of expression
01. Capabilities
the missing link
between BC & aggregate
#structure
The step in between
bounded context - part of domain space with coherent, common ubiquitous language
aggregate - cluster of domain object under single identity & modified always within shared transaction scope
...
BC of a Salon Receptionist
...
Source / Inspiration:
>> "Just Enough
Software Architecture"
George Fairbanks
"(...) at some point the number of classes is sufficiently large that developers reach for even larger abstractions to make sense of the program. It is not a question of their being forced into new abstractions; it is a matter of using the ones suited for the scale or complexity of the problem."
To be comprehensible, your software should be structured so that it reveals a story at many levels . Each level of nesting tells a story about how those parts interact. A developer who was unfamiliar with the system could be dropped in at any level and still make sense of it, rather than being swamped.
"Stolen" example
idea ref.:
Simon Brown
the Cognitive Load?
How to reduce
>> fluent LoD (Level-of-Detail)
>> hierarchical (tree-like) navigation
>> Single Responsibility Principle
>> limit the context of work
Source / Inspiration:
>> "Thinking in Promises"
Mark Burgess
"Commands fan out into unpredictable outcomes from definite beginnings, and we go from a certain state to an uncertain one. (...) promises converge towards a definite outcome from unpredictable beginnings, leading to improved certainty."
"A promise is a stated intention."
Properties of Contract
>> 1. represents the "promise"
>> 2. contains everything you need to know
to "consume" whatever's behind
>> 3. is expressed in Ubiquitous Language
Properties of Capability
>> 1. addresses a "concern"
>> 2. oriented on certain "abstractions"
>> 3. exposes a "contract"
>> "concern" & "abstractions" define
boundaries
>> only "contract" visible externally
>> all behind "contract" is an
implementation detail
What's Capability?
>> contracts are ARTIFACTs (work products)
Scope of action
unit (atomic) business operation,
how many capabilities affected?
>> mutation: single
>> non-mutation: single+
Scope of action
?
example
Coupling VS Cohesion
it's all about balance
Source / Inspiration:
>> "A Philosophy of Software Design"
John Ousterhout
"An abstraction is a simplified view of an entity, which omits unimportant details. Abstractions are useful because they make it easier for us to think about and manipulate complex things."
"If users must read the code of a method in order to use it, then there is no abstraction: all of the complexity of the method is exposed."
"The best modules are deep: they have a lot of functionality hidden behind a simple interface. A deep module is a good abstraction because only a small fraction of its internal complexity is visible to its users."
"The benefit provided by a module is its functionality. The cost of a module (in terms of system complexity) is its interface. (...) the smaller and simpler the interface, the less complexity that it introduces."
Deep capabilities
>> what's the depth?
>> shallow VS deep
>> contract is cost, content is value
Capability nesting
>> hides the abstractions
>> reduces cognitive load
>> hierarchical structuring
>> flat access
>> more strategic -> more tactical
Capability nesting
02. Classifying abstractions
not necessarily "data model" though ...
#information
ERD out!
Classes of abstractions
>> inventories
>> transactions
>> snapshots
>> append logs
>> workflows
>> accumulators
Data Model shouldn't
>> "state" anti-pattern
>> horse that does "yee-haw"
drive your design
Idea ref.:
Einar Høst
X-centricity
>> pivot abstraction
>> for splitting/sharding/tenancy
of the design
Source / Inspiration:
>> "Vertically Integrated Architectures"
Jos Jong
The IR Model
(IR = Item-Relationship):
Forest of data
>> consistency (in time)
>> nested hierarchIES
>> relationships across
(instead of traditional relations)
Forest of data
(instead of traditional relations)
>> what can be archived
>> shared scalability properties
>> visibility isolation
03. Business Logic quirks
where's the catch?
#functionality
Death by 1000 (domain) events
How NOT to make a booking?
Is it STILL Business Logic?
S
I
D
E
E
F
F
E
C
T
S
Is SE ... an async event?
>> consistency
>> inevitability
>> reconcilable
>> price of asynchrony
SE VS Business Logic
>> not *real* Business Logic
>> event is a part of contract
>> event-based, yet synchronous
>> redundancy (to help)
Wait ... there's
one more thing
Tribal
Wisdom
Domain Invariants
>> declarative
>> span across capabilities / "trees"
>> always true (traceable)
>> incl. across time (!)
>> made explicit
>> foundation, extremely painful to change
04. Ownership over data
yay or nay?
#information #functionality
Ownership over data?
>> when is it not practical?
>> does replication make (always) sense?
>> are "views" ("queries") business logic?
pragmatism FTW
Ownership over data?
simple cases
>> details view
>> form view
Ownership over data?
tricky cases
>> key entity
>> 2ndary entity: limited
>> 2ndary entity: unlimited
>> batch jobs /operational reports (***)
Ownership over data?
tips & tricks
>> A. join in memory (separate queries)
>> B. snapshotted data (append-only)
>> C. (mat.) views as parts of business logic
>> D. event-based replication
>> E. technical replication
Ownership over data?
practical examples
>> 1. calendar
>> 2. offer catalogue
>> 3. operational report - appointments
>> 4. dynamic list of marketing recipients
05. Dispelling myths
the worst of a kind
#hate
DESIGN.
IS.
NOT.
ABOUT.
FUCKING.
CODE.
but.
about.
domain.
model.
1. "mine" abstractions (modeling)
2. propose (structuring) conventions
3. map (conventions + abstractions) to code
4. rinse & repeat
DDD in a nutshell
easy peasy lemon squeezy
CQ(R)S
>> a narrow-usage heuristic
>> could be replaced with "redundancy"
>> comes in various "flavors":
____ * accumulator
____ * (materialized) views
____ * domain-event replication
____ * integration-event replication
is ...
Event-Sourcing
>> VERY limited applicability (heuristic)
>> ... for cases where Domain Event
schema is a domain inherent property
>> an often under-estimated cost
>> in fact limited benefits
has ...
Async sounds great
>> reactive == MORE complex
>> if interaction pattern is sync, don't make the code artificially async
>> there are alternatives
but doesn't have to be the best option
Books & Sources (1/2)
>> "Vertically Integrated Architectures"
Jos Jong
>> "A Philosophy of Software Design"
John Ousterhout
>> "Just Enough Software Architecture"
George Fairbanks
>> "Thinking in Promises"
Mark Burgess
Books & Sources (2/2)
>> "Software Design X-Rays"
Adam Tornhill
>> "Your Code as a Crime Scene"
Adam Tornhill
>> "Essentialism"
Greg McKeown
>> "Inspired"
Marty Cagan
Thank you!
Contact:
Sebastian Gebski, CTO @ Shedul/Fresha
@liveweird - https://no-kill-switch.ghost.io
