Most web applications are dealing with non-trivial tasks, such as calculating prices and billing items, booking reservations, etc. Each of these topics is a complex domain: there are many requirements, some business rules, and many interactions to handle. If the software project is not organized, architectured, complexity goes up and the project quickly derails.
This talk has a look at how we move from requirements to software architecture, and then to code. We will discuss strategies to discover a domain, tools to model it and share it with the team, and finally patterns to express it in code.
Amongst those, there are Domain-Driven Design and Enterprise Architecture. Though they can't be fully applied every time, I believe some of their techniques can be useful every day. And every developer could benefit from tools to get a better understanding of what they are coding and how to express their intention in their code.
Tackling complex domains:
strategies and pa,erns
Romaric Drigon @ Webmardi, Lausanne, 04.08.2020
So#ware engineer @ ASIT
Most web apps deals
with non-trivial tasks
Online booking, e-commerce
with stock management and invoicing...
How to code those?
- what to code? speciﬁca/on?
- tests? edge cases?
Easy to maintain
- long life)me
Let me tell you a story:
developping an ERP so0ware
Including many modules
This project in numbers
• 8 developers
• 6 months
• we wrote 59 769 lines of PHP (tests not included)
• using Symfony framework
• 584 classes
It could have been an horror story!
Domain-Driven Design to the rescue
What is a domain?
A sphere of knowledge, inﬂuence, 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
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
1. Understanding the Domain
What is legal case management?
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-speciﬁca3on"
Interviews and whiteboard discussions
Reviewing wireframes / mockups
“A method to discover business processes”
Picture from h-ps:/
2. Expressing the Domain
How to get the "model" of the Domain?
“A common, shared, vocabulary,
where words have a speciﬁc and
well-deﬁned meaning in your applica3on”
“Divide and conquer”
Source : Mar+n Fowler, h2ps:/
Think of Bounded Contexts
But it does not have to be separate apps:
bundles, packages, modules, or folders...
3. A "rich" Domain Model
To capture and code what we learnt
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...
• inside Drive Bounded Context
• En##es are objects containing both
business logic and persisted data
• we are using an ORM to handle
• non-persisted objects in Model folder
Project was using Symfony framework and
With business logic
Some business rules are not easy to code.
• many branches (complexity)
• hard to follow
• process spans over several days
Then we need help more speciﬁcally with
how to structure our code
4. Architectural pa/erns
To structure something complex
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
Watch out for the mess, though
Schema up there is dumped from Symfony workﬂow component
PHP implementa,ons I recommend are Tac,cian, or Symfony Messenger
5. Design pa,erns
To simplify a piece of code
It worked out pre,y well
The part of the project I contributed to
• Major deadlines were met
• Team could integrate new developers
• First version was released, and
development of new features con;nues
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
Feedback over pa-erns
• + makes code easier to understand
• + allows to decouple sub-units:
• facilitates team work (less Git conﬂicts)
• + usually easier to test
• - requires more explana;on at the beginning
Thank you for your a,en.on!