Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Domain-Driven Design in PHP
Search
Wojciech Sznapka
September 27, 2014
Programming
4
2k
Domain-Driven Design in PHP
Wojciech Sznapka
September 27, 2014
Tweet
Share
More Decks by Wojciech Sznapka
See All by Wojciech Sznapka
Getting started with Firebase in Angular
sznapka
1
57
PiHome – home automation done with Raspberry PI and Python
sznapka
0
350
Big data in the trenches
sznapka
1
290
PiHome – home automation done with Raspberry PI and Python
sznapka
0
340
Map-Reduce patterns
sznapka
3
230
An introduction to AngularJS
sznapka
0
230
Achieving wise architecture with Symfony2 @ SPUG#5
sznapka
2
170
Smart development environments
sznapka
2
1.6k
Automated tests - facts and myths
sznapka
1
1.6k
Other Decks in Programming
See All in Programming
全部見せます! クラシルリワードのSwiftTesting移行プロジェクト
uetyo
0
210
Regular Expressions, REXML, Automata Learning
makenowjust
0
220
オートマトン学習しろ / Do automata learning
makenowjust
3
130
Go1.23で入った errorsパッケージの小さなアプデ
kuro_kurorrr
2
400
僕が思い描くTypeScriptの未来を勝手に先取りする
yukukotani
9
2.4k
Scala アプリケーションのビルドを改善してデプロイ時間を 1/4 にした話 | How I improved the build of my Scala application and reduced deployment time by 4x
nomadblacky
1
180
KSPの導入・移行を前向きに検討しよう!
shxun6934
PRO
0
280
Scala におけるコンパイラエラーとの付き合い方
chencmd
2
430
意外とフォントが大事だった話 / Font Issues on Internationalization
fumi23
0
110
サーバーレスで負荷試験!Step Functions + Lambdaを使ったk6の分散実行
shuntakahashi
6
1.6k
ECMAScript、Web標準の型はどう管理されているか / How ECMAScript and Web standards types are maintained
petamoriken
3
390
From Idea to IDE: Developing Plugins for Android Studio
thisaay
1
220
Featured
See All Featured
VelocityConf: Rendering Performance Case Studies
addyosmani
322
23k
What's in a price? How to price your products and services
michaelherold
242
11k
Into the Great Unknown - MozCon
thekraken
29
1.4k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
23
1.7k
Debugging Ruby Performance
tmm1
72
12k
How STYLIGHT went responsive
nonsquared
93
5.1k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
248
20k
Designing with Data
zakiwarfel
98
5k
Optimising Largest Contentful Paint
csswizardry
31
2.8k
Statistics for Hackers
jakevdp
794
220k
Building Flexible Design Systems
yeseniaperezcruz
325
38k
How GitHub (no longer) Works
holman
310
140k
Transcript
Once upon the time, in ancient Greece...
Hercules got into to serious troubles...
King Eurystheus ordered Hercules to clean up Augeas' stables
The stables was complex and full of mud
As accounted for real hero, Hercules used nifty trick
He changed flow of a river and directed it into
two holes in opposite walls
The task has been solved in a single day
Unfortunately there’s no such heroic attempts in history of software
development
Instead of heroes, you need ...
Domain-Driven Design in PHP Wojciech Sznapka PHPCon 2014
Hi! I'm Wojciech Sznapka * Head Of Development @ Cherry
Poland * Coding since 10 years * Interested in architecture, Big Data, Ice Hockey
DDD essentials
Domain-Driven Design is a way of developing complex software ...
... by focusing on core domain first ...
... modeling and abstracting reality using “building blocks” and proven
design patterns ...
and delaying technical decisions as much as possible.
It’s all about the domain
You can’t build properly working software without deep domain knowledge
But, you won’t understand the whole domain at once. It's
an iterative process
You need evolving model
It’s crucial to have common understanding from day one...
… and to speak Ubiquitous Language with stakeholders and Domain
Experts
The model
Good model act as Ubiquitous Language
None
It reflect domain logic as much as possible
It's build using layers * User interface * Application layer
* Domain layer * Infrastructure layer
* source: Domain-Driven Design Quickly by InfoQ
User interface presents and interprets user commands
Application layer coordinates activities. It's ought to be very thin
Domain layer is the heart of the system, responsible for
business logic
Infrastructure layer acts as support, providing persistence, tools, etc.
Let’s speak about entities, DDD first class citizens
Entity represents a business being
Entity is not a simple Data Transfer Object or data
container
Therefore avoid anemic entities . Good entity should provide behavior,
besides identity and attributes!
Infrastructure layer helps with persisting entities (using a backing service*
of your choice) * http://12factor.net/backing-services
None
Entities are supported by value objects
Value objects conceptually does not provide any identity, so they
can be shared
To achieve that, value objects need to be immutable* *
http://blog.sznapka.pl/immutable-value-objects-in-php
The important fact: value objects are type hintable
None
Large graph of entities can be difficult to handle consistently
DDD introduced a term Aggregate which is collection of objects
...
... bound with aggregate root and hiding underlying objects from
the external world
Aggregates provides a coherent interface to operate on sub-graph of
the model
During development of ubiquitous language you’ll find that some actions
don’t belong to any object
Such situations are solved with domain services
Services employ various entities, value objects, factories, repositories to do
their job
None
When dealing with complex objects, their creation could be complex
and it's good to hide that logic
Well known factories will do the trick
Factory hides instantiation complexity and enables interchangeability in the future
None
While factories help with objects creation, it is equally important
to abstract objects retrieval
Repository design pattern abstracts objects retrieval from a storage
It’s extremely important to place all data access logic in
repositories
Infrastructure layer helps a lot here
It uses your ORM library to build specific queries or
use other vendors to obtain objects
More important fact is that repository* is replaceable * like
the most of DDD building blocks
Model boundaries
It’s important to draw bold borders inside your system, as
it grows and becomes complex
None
None
None
When different stakeholders start to confuse you with vocabulary
It's good time to think about bounded contexts
“Bounded Context is a central pattern in Domain-Driven Design”* *
http://martinfowler.com/bliki/BoundedContext.html
It’s quite sure, that bounded contexts will share common concepts
Therefore create context map to outline points of contact between
them
Also, distinguish core domain from generic ones...
Choose proper bounded context collaboration model
Shared kernel, when two teams work closely on subset of
domain
They acts as partners, and access each other bounded context
with common code
Customer-Supplier, when upstream team provides an API and downstream teams
consume it
Customer team can influence Supplier to modify model
Open Host Service, when interface is defined by widely known
protocol
It's typical SOA approach
Or: * Partner * Conformist * Separate ways * Anticorruption
layer * Published language
Taming the beast A.K.A. Summary
OOP is not enough
DDD is great for complex problems
You can pick parts of DDD and still benefit out
of it
You should be aware of duplication and complex structures in
DDD
DDD doesn't care about your fancy: Symfony/Zend Framework/Laravel * *
delete where inapplicable
Be PRAGMATIC! * * take care about your core domain
in the first place
Thanks for your attention! Ask me anything blog.sznapka.pl
[email protected]
twitter.com/sznapka
Your feedback is important! https://joind.in/11844