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.
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
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.
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!?
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)
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?
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...
...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.
ask
Stress on why CQRS is a “natural” good choice. Explain the differences btw simplified and “full” cqrs architecture