SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez nos Conditions d’utilisation et notre Politique de confidentialité.
SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez notre Politique de confidentialité et nos Conditions d’utilisation pour en savoir plus.
One of the main advantages of PHP is that it allows you and your company to build up projects in no time and with immediate feedback and business value. Sometimes, however, fast growth and unprevented complexities could make your codebase more and more difficult to manage as time passes and new features are added.Domain Driven Design can be an elegant solution to the problem, but introducing it in mid-large sized projects is not always easy: you have to deal with difficulties at technical, team and knowledge levels. This talk focuses on how to approach the change in your codebase and in your team mindset without breaking legacy code or stopping the development in favor of neverending refactoring sessions.
...which means that transitions should never be painful, cause troubles nor resulting in neverending refactoring sessions.
SC bootstrapped in 3 months, features added one after another, thus resulting now in some problems controlling the codebase and solving bugs.
hands up people working on projects younger than 6 months. now older. from the latter, who thinks that their codebase already need some refactoring / has problems.
what is a supporting subdomain. what is a generic subdomain. why not in crudish apps
stress “don’t start designing from data”. stress on “introspect processes” to introduce the next Matrix slide.
Stress on why CQRS is a “natural” good choice. Explain the differences btw simplified and “full” cqrs architecture
Brownfield Domain Driven Design
Bring your project to the next level
without breaking things (nor people)
- PHP developer
- Team leader / Software engineer at Rocket Labs, Berlin
We proudly run Seller Center, the largest Rocket Internet
Popular clients: Zalando (Europe), Lazada (south Asia),
Linio (south America), Global Fashion Group
More challenging and fun than greenfield!
Majority of cases.
Open knowledge harder to find.
Examples start from the assumption of a greenfield.
“Greenfield is exciting at first, but taking a brownfield project and
giving it new life, well, is just priceless!”
Me on Twitter
Why Domain Driven Design?
● Non-trivial domain model
● Linguistic boundaries applied to
● Design and code reflect the
same concepts 1:1
● Iterative knowledge distillation
● Both tactical and strategic tools
No, let’s not
Yes, we can
● In your core domain
● In heavy business-logic
parts of your application
● In strategic supporting
Where should I apply it?
i.e. where you make most of your
Can we outsource or buy it? Then it’s
one of those.
Is it difficult? How do we change?
● learn new concepts
● mindshift is not immediate
● eradicate CRUD design
● design business first, then data
● handle the change
● manage adaptation time
● active part of design process
● involve business experts
● face potential change
● introspect processes
*all the bad things in this slide are written with Comic Sans and poor contrast on purpose.
BIG BALL OF “MUD”
Hey, at least it works...
Don’t know exactly how, but
Where to start from?
Ok, we need some Repositores, then a Domain/Model
directory which will contain AggregateRoots, Entity,
Yes! Oh, don’t forget about Domain Services, the
Application layer and a new event system which we’ll
What about a new structure for controllers and UI? They’re
definitely part of our Bounded Context! Let’s reuse our DB
connection class, so we also need a Shared Kernel.
● Define your core domain,
supporting and generic
● Define the relations between
them and with other external
● Define behavior at
boundaries and grey areas
➔ Describe your business through events, what/who caused them, what is
the “subject” of your events.
➔ Invite the “right people”, brainstorm, discuss, reach a first representation of
your business model. Just let it happen.
DON’T JUST SKIP IT!
The UL is what takes all things (and people) together.
- It dramatically lowers communication and cognitive load, providing
a common ground, understandable by anyone.
- It defines and explains what domain objects are, how they behave
and the relations between them.
How can you even start coding something that you
haven’t defined in terms of concept and behavior!?
Yeah! We’re finally writing
some code now!
Markers and sticky notes were
making me feel so uncomfortable...
The evil facilitator shouted at
me when I said “cronjob” :’(
We were always talking about
“Product”, but I think I will call this
class “Article”. Buhahaha!
Where should we start applying DDD from?
Let’s start with our
Did someone at
least read the
Blue and Red
Let’s start with a
Keep your UI away
CQRS? Yes, please!
● Expresses your business
● Changes the state of the
● Doesn’t expose internal
● Shapes information based
on representation type
● Never changes the state of
● Exposes internal state
Haiku of the code duplication
CQRS is applied,
duplication comes in.
Everything is quiet.
Change your state through events
Unit Of Work