Most web apps deals
with non-trivial tasks
Online booking, e-commerce
with stock management and invoicing...
Slide 4
Slide 4 text
How to code those?
☑
Easily!
- what to code? specifica/on?
☑
Bug free
- tests? edge cases?
☑
Easy to maintain
- long life)me
Slide 5
Slide 5 text
Let me tell you a story:
developping an ERP so0ware
Slide 6
Slide 6 text
Including many modules
Slide 7
Slide 7 text
This project in numbers
• 8 developers
!"""""""
• 6 months
• we wrote 59 769 lines of PHP (tests not included)
• using Symfony framework
• 584 classes
Slide 8
Slide 8 text
It could have been an horror story!
Slide 9
Slide 9 text
Domain-Driven Design to the rescue
Slide 10
Slide 10 text
What is a domain?
A sphere of knowledge, influence, or ac6vity. The subject area to
which the user applies a program is the domain of the so?ware.
— Eric Evans
In my project, it was legal case management
Slide 11
Slide 11 text
We want a useful model of that domain
“With Domain-Driven Design, it’s a model
of the business domain that ma9ers most.”
— Vaugh Vernon, Implemen1ng Domain-Driven Design
So we need to understand the domain, to model it
and to code this model in our project
Slide 12
Slide 12 text
1. Understanding the Domain
What is legal case management?
Slide 13
Slide 13 text
How to discover a domain?
Get access and discuss with business people,
for whom you are making the so6ware (users):
They are stakeholders
It doesn't work well in closed organiza3ons (silos); with remote
agencies; or when doing "communica3on-through-specifica3on"
Slide 14
Slide 14 text
Interviews and whiteboard discussions
Slide 15
Slide 15 text
Reviewing wireframes / mockups
Slide 16
Slide 16 text
Drawing workflows
Slide 17
Slide 17 text
Event Storming
“A method to discover business processes”
Picture from h-ps:/
/medium.com/techlabs-emag/what-is-event-
storming-ed1a0e519fad
Slide 18
Slide 18 text
2. Expressing the Domain
How to get the "model" of the Domain?
Slide 19
Slide 19 text
Ubiquitous language
Slide 20
Slide 20 text
“A common, shared, vocabulary,
where words have a specific and
well-defined meaning in your applica3on”
Think of Bounded Contexts
as microservices
But it does not have to be separate apps:
bundles, packages, modules, or folders...
Slide 27
Slide 27 text
3. A "rich" Domain Model
To capture and code what we learnt
Slide 28
Slide 28 text
Our code should contain
a Domain Model,
a set of classes
describing the business
≠ infrastructure code,
which is dealing with technical details,
such as database access, e-mail sending...
Slide 29
Slide 29 text
In example
• inside Drive Bounded Context
• En##es are objects containing both
business logic and persisted data
• we are using an ORM to handle
database read/write
• non-persisted objects in Model folder
Project was using Symfony framework and
Doctrine ORM
Slide 30
Slide 30 text
Expressive code
With business logic
Slide 31
Slide 31 text
Anemic model
Slide 32
Slide 32 text
Bloated services
Slide 33
Slide 33 text
Some business rules are not easy to code.
• many branches (complexity)
• hard to follow
• process spans over several days
• etc.
Then we need help more specifically with
how to structure our code
Slide 34
Slide 34 text
4. Architectural pa/erns
To structure something complex
Slide 35
Slide 35 text
No content
Slide 36
Slide 36 text
Events: dispatcher pa,ern
Our code throw events, listeners react to those
• allows to decouple
• avoids duplica0on
• listeners tend to be small classes
• easier to test
Slide 37
Slide 37 text
Watch out for the mess, though
Slide 38
Slide 38 text
Workflow
Schema up there is dumped from Symfony workflow component
Slide 39
Slide 39 text
Commands bus
PHP implementa,ons I recommend are Tac,cian, or Symfony Messenger
Slide 40
Slide 40 text
5. Design pa,erns
To simplify a piece of code
Slide 41
Slide 41 text
No content
Slide 42
Slide 42 text
Final word
Slide 43
Slide 43 text
It worked out pre,y well
The part of the project I contributed to
was successful:
• Major deadlines were met
• Team could integrate new developers
easily
• First version was released, and
development of new features con;nues
Slide 44
Slide 44 text
Feedback over strategies
1. Meet business people: great, but not always easy
2. Use a common vocabulary
• Ubiquitous Language
3. Split big apps into smaller pieces
• Bounded Contexts
4. Code a rich Domain Model
• business classes are the crown jewels of your app
Slide 45
Slide 45 text
Feedback over pa-erns
• + makes code easier to understand
• + allows to decouple sub-units:
• productivity++
• facilitates team work (less Git conflicts)
• + usually easier to test
• - requires more explana;on at the beginning
Slide 46
Slide 46 text
Thank you for your a,en.on!
h,ps:/
/romaricdrigon.github.io/