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.

1. Brownfield
Domain Driven
Design
Bring your project to the next level
without breaking things (nor people)

2. About me
@nicolopigna
- PHP developer
- Team leader / Software engineer at Rocket Labs, Berlin
We proudly run Seller Center, the largest Rocket Internet
Marketplace solution.
Popular clients: Zalando (Europe), Lazada (south Asia),
Linio (south America), Global Fashion Group

3. Why “Brownfield”?
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

4. Why Domain Driven Design?
● Non-trivial domain model
● Linguistic boundaries applied to
the code
● Design and code reflect the
same concepts 1:1
● Iterative knowledge distillation
● Both tactical and strategic tools

5. No, let’s not
CRUDish applications
Generic subdomains
Yes, we can
● In your core domain
● In heavy business-logic
parts of your application
● In strategic supporting
domains
Where should I apply it?
i.e. where you make most of your
money.
Can we outsource or buy it? Then it’s
one of those.

6. Is it difficult? How do we change?
Team
● learn new concepts
● mindshift is not immediate
● eradicate CRUD design
● design business first, then data
structures
Management
● handle the change
● manage adaptation time
● active part of design process
Organisation
● involve business experts
● face potential change
● introspect processes

8. Your brownfield
Monolithic
High-coupling
Single-data-store
We-tried-to-build-some-unit-tests-but-it’s-impossible-to-mock-
everything-or-refactor-let’s-use-integration-tests-instead.
*all the bad things in this slide are written with Comic Sans and poor contrast on purpose.
Huge
Change-here-break-there

9. BIG BALL OF “MUD”

10. BIG BALL OF “MUD”
Hey, at least it works...
Don’t know exactly how, but
it does!

11. Where to start from?
Ok, we need some Repositores, then a Domain/Model
directory which will contain AggregateRoots, Entity,
ValueObjects, etc.
Yes! Oh, don’t forget about Domain Services, the
Application layer and a new event system which we’ll
definitely need.
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.

13. Instead...

14. Context mapping
● Define your core domain,
supporting and generic
subdomains
● Define the relations between
them and with other external
systems
● Define behavior at
boundaries and grey areas

15. Event storming
➔ 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.

16. DON’T JUST SKIP IT!
Ubiquitous Language
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!?

17. Ok. Finally...

18. 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!
product.name is
varchar(50) or
varchar(255)?

19. Where should we start applying DDD from?
Are we
confident with
DDD, SOLID
and refactoring
strategies?
Let’s start with our
Core Domain
yes
Did someone at
least read the
Blue and Red
books?
no
yes
no
Let’s start with a
Supporting
Subdomain
Read them...

20. Keep your UI away
CONTROLLERS
FORMS
TEMPLATES
YOUR FAVORITE
MVC FRAMEWORK
Services
(Endpoint /
Private)
Model
Repositorie
s
Commands
Events
✗
✓

21. CQRS? Yes, please!
Your database
Command
“Write” Model
● Expresses your business
behavior
● Changes the state of the
system
● Doesn’t expose internal
state
Query
● Shapes information based
on representation type
● Never changes the state of
the system
● Exposes internal state
“Read” Model

22. Haiku of the code duplication
CQRS is applied,
duplication comes in.
Everything is quiet.

23. Change your state through events
DoSomethingCommand
Service
Unit Of Work
load($aggregateRootId)
AggregateRoot
doSomething()
AggregateRootAggregateRoot
● Something
Done
Repository
AggregateRootcommit()
flushEvents()
Events
persist($events)
EventBus
post($events)

24. Event sourcing? Read storage?
IT’S A TRAP!

25. Event sourcing? Read storage?
1 - Added architectural complexity
Event application
Event replaying
Snapshots

26. Event sourcing? Read storage?
1 - Added architectural complexity
Event application
Event replaying
Snapshots 2 - Infrastructure and costs
Dedicated data storage (forget MySQL!)
Remote communication (via message
broker, REST interface, etc.)

27. Event sourcing? Read storage?
1 - Added architectural complexity
Event application
Event replaying
Snapshots 2 - Infrastructure and costs
Dedicated data storage (forget MySQL!)
Remote communication (via message
broker, REST interface, etc.)
3 - Eventual consistency
Think about consequences
Implement resilient behavior
Advanced UI techniques

28. Oh! Think twice!

29. Protect your new code!
STRICT RULE: Code from the Big Ball of Mud
must not leak into the new BCs nor vice-versa.
THEN HOW DO THEY
INTERACT? BY MAGIC?

30. MEET THE
ANTI-CORRUPTION LAYER

31. MEET THE
ANTI-CORRUPTION LAYER
YOU SHALL NOT PASS!!!

32. MEET THE
ANTI-CORRUPTION LAYER
YOU SHALL NOT PASS!!! At least, not before I can
convert you to something
meaningful for your
destination context...

33. Anti-corruption layer
Legacy context
Database
ACL
Adapters
Converters
Identity
Maps
Bounded Context

34. Anti-corruption layer
Legacy context
Database
ACL
Adapters
Converters
Identity
Maps
I’m here to stay!!!
Bounded Context

35. Anti-corruption layer
Legacy context
Database
ACL
Bounded Context
Adapters
Converters
Identity
Maps
place
interfaces here
I’m here to stay!!!

36. Anti-corruption layer
Legacy context
Database
ACL
Adapters
Converters
Identity
Maps
I can fly away, now!
Bounded Context
place
interfaces here

37. What happens next?
My new shiny BC
Our soon-to-be-shrunk BBoM
Anti-corruption layer

38. What happens next?
My new shiny BC
Our shrinking BBoM
Anti-corruption layer
My second shiny
BC

39. What happens next?
My new shiny BC
Our shrinking BBoM
Anti-corruption layer
My second shiny
BC

40. What happens next?
My new shiny BC
Our shrinking BBoM
Anti-corruption layer
My second shiny
BC
But of course it’s
easier now!

41. From distributed Bounded Contexts
to μServices
μS = lim Bc(nuc)nuc→ 1

42. Thank you
for listening!
Time for muddy questions!