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

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 -

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


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

>> 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



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 ...


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


>> 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?


Death by 1000 (domain) events

How NOT to make a booking?

Is it STILL Business Logic?



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


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




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


>> a narrow-usage heuristic

>> could be replaced with "redundancy"

>> comes in various "flavors":

____ * accumulator

____ * (materialized) views

____ * domain-event replication

____ * integration-event replication


is ...


>> 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!

Sebastian Gebski, CTO @ Shedul/Fresha
@liveweird -

DDD - the lost chapters

By Sebastian Gębski

DDD - the lost chapters

How to design a calendar? :)

  • 386
Loading comments...

More from Sebastian Gębski