1giovedì 23 maggio 13

Goals

Quickly sketch a model for a complex system

Have the basic concepts of Domain-Driven Design emerge without prerequirements.

2giovedì 23 maggio 13

3giovedì 23 maggio 13

In practice...

Stick a paper roll on a wall.

We might have up to 25 metres of modeling space

Collaborative work

4giovedì 23 maggio 13

Yes, I mean that much space...

5giovedì 23 maggio 13

Domain EventsMight 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 complex6giovedì 23 maggio 13

Hint:

...it gets a lot more interesting if we explore areas we don’t know.

... with the domain expert.

... with concrete examples.

7giovedì 23 maggio 13

8giovedì 23 maggio 13

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

9giovedì 23 maggio 13

10giovedì 23 maggio 13

FLOW (team decided this way)

Team decided to start from the right... we called it WOLF instead of FLOW then.

11giovedì 23 maggio 13

12giovedì 23 maggio 13

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

13giovedì 23 maggio 13

14giovedì 23 maggio 13

Aggregates

“How do I correctly define aggregates?” ... yes, that’s THE question

Have a look to DDD mailing lists, if you don’t believe it

Our goal is to define aggregates outside in

15giovedì 23 maggio 13

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

16giovedì 23 maggio 13

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

17giovedì 23 maggio 13

Invariants

Forget data:An aggregate can accept or reject a command.

Upon which information?

What is always guaranteed for our aggregate?

18giovedì 23 maggio 13

19giovedì 23 maggio 13

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

20giovedì 23 maggio 13

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.

21giovedì 23 maggio 13

22giovedì 23 maggio 13

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

23giovedì 23 maggio 13

LanguagesIn 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

24giovedì 23 maggio 13

25giovedì 23 maggio 13

Bounded Contexts

Highlight the different models in playSoftware components

Legacy components

Languages used

They’re a realistic snapshot, not the image of our wishes...

26giovedì 23 maggio 13

27giovedì 23 maggio 13

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.

28giovedì 23 maggio 13

29giovedì 23 maggio 13

TestsSome 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] fits very well :-)

30giovedì 23 maggio 13

31giovedì 23 maggio 13

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.

32giovedì 23 maggio 13

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

33giovedì 23 maggio 13

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.

34giovedì 23 maggio 13

35giovedì 23 maggio 13