Event based modeling - eng

Goals
Quickly sketch a model for a complex
system
Have the basic concepts of Domain-
Driven Design emerge without
prerequirements.
2giovedì 23 maggio 13

In practice...
Stick a paper roll on a wall.
We might have up to 25 metres of
modeling space
Collaborative work

Yes, I mean that much
space...

Domain Events
Might resemble an Activity Diagram
...but we’re not doing UML
Events cannot be discussed. They happened. Deal
with it.
System-wide view.
Every team start to imagine a domain, instead
of asking to the domain expert... :-(
Real system might be a lot simpler
Real system might be a lot more complex

Hint:
...it gets a lot more interesting if we
explore areas we don’t know.
... with the domain expert.
... with concrete examples.

Event Origin
Events do not just appear out of the
blue:
some originate from user actions
some originate in external systems
some are generated by time
...some are originated as a response to other
events

FLOW (team decided this way)
Team decided to start
from the right... we
called it WOLF instead
of FLOW then.

Event Flow
Search for predecessors or
consequences of our events
Using verbs in the past helps clarify the
semantics:
“wedding” is not an event, it’s a process (don’t
tell it to your wife)
More actors are joining our system

Aggregates
“How do I correctly deﬁne
aggregates?” ... yes, that’s THE
question
Have a look to DDD mailing lists, if you don’t
believe it
Our goal is to deﬁne aggregates outside
in

Deﬁnition
An aggregate represents consistency
unit: a group of classes changing state
together.
...but it’s not always clear enough...
...how big these objects are?
...how do they look like?
It has something to do with transactional
boundaries but ours might be wrong.

Rule of thumb
To sketch aggregate boundaries we can
think about
Informations deleted together
Informations moved together
Informations distributed together
...but that’s still a little too data-centric

Invariants
Forget data:
An aggregate can accept or reject a
command.
Upon which information?
What is always guaranteed for our
aggregate?

Aggregates
Shifting the focus on invariants helps
aggregate modeling
Smaller, more controllable units
Variations are propagated via Domain Events
A better domain exploration
The whole is eventually consistent

Example
Max particpants per class:
Where does this constraint come from?
Classroom capacity? --> accept and look for a
better location (if there’s time available)
Class physiological limit --> stand-by and
waiting list or propose next edition
No accidental complexity requirements.

Subdomains
Business level system partitioning
Some portions are core for our company
competitivity.
Es. things that are going to sell more.
Other are simply necessary, but no key
differentiators.
Es. invoicing: it’s needed but no customer will
choose us for the invoice layout. Good enough is
good enough.

Languages
In mid/large-sized companies we’ll have
many stakeholders.
Different goals
different backgrounds,
different languages
...will require different models
Caution: we aren’t talking about Bounded
Contexts...yet

Bounded Contexts
Highlight the different models in play
Software components
Legacy components
Languages used
They’re a realistic snapshot, not the
image of our wishes...

Users & Personas
Got a chance to include users and their
categories in the picture? Why not!?
We can highlight personas and make
them part of the model...
...especially if this triggers an
interesting conversation with the
domain experts.

Tests
Some interesting details might emerge
during the conversation. Why not take a
note?
In natural language
...according to BDD lingo (--> Cucumber)
In an event driven perspective, the
structure Given [events] When
[command] Then [event] ﬁts very well :-)

Takeaways
Model of a complex enterprise system
ignoring data
... what if data model is part of the problem?
Tight focus on system behavior and not
on static data structure.

Takeaways
The model is created collectively in a
cooperative learning fashion and
provides a good high-level view.
Are you sure DEs know everything?
Time-boxed, but....
Space-boxed but....

Legacy Systems
The sketched model is close to an “ideal
system model”
It’s NOT the starting point to rewrite from scratch!
But it’s a good reference to establish a direction
Legacy components that do not belong in the
domain emerge like accidental complexity.
batch operations, legacy stuff feel really
inappropriate.

Event based modeling - eng

More Related Content

What's hot (18)

Viewers also liked (18)

Similar to Event based modeling - eng (20)

More from Alberto Brandolini (15)

Recently uploaded (20)

Event based modeling - eng