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
48
PiHome – home automation done with Raspberry PI and Python
sznapka
0
320
Big data in the trenches
sznapka
1
250
PiHome – home automation done with Raspberry PI and Python
sznapka
0
320
Map-Reduce patterns
sznapka
3
230
An introduction to AngularJS
sznapka
0
230
Achieving wise architecture with Symfony2 @ SPUG#5
sznapka
2
160
Smart development environments
sznapka
2
1.6k
Automated tests - facts and myths
sznapka
1
1.6k
Other Decks in Programming
See All in Programming
AppDeveloperCon 2024 EU: Building polyglot developer experiences in 2024
salaboy
0
380
ファイル先頭の use の意味、説明できますか? 〜PHP の namespace と autoloading の関係を正しく理解しよう〜 / namespace and autoloading in php
okashoi
2
470
Kotlinを用いたDSL的な設計手法と使用上の注意
kohii00
3
530
プロンプトエンジニアリング入門
tomokusaba
2
980
せっかくモデル図描くのなら、嬉しいことが多い方がいいよね!
kuboaki
1
1.8k
品質が高いコードって何?Rev2.1
ickx
1
490
PHP8の機能を使って堅牢にコードを書く
fendo181
6
2.6k
Parallel Socket Communication in Swift
s_shimotori
0
250
受託開発でGitLab CI を活用していく
xiombatsg
1
130
PHPerKaigi 2024〜10年以上動いているレガシーなバッチシステムを Kubernetes(Amazon EKS) に移行する取り組み〜
tshinowpub
1
220
Migrating to Signals: A Practical Workshop
manfredsteyer
PRO
0
280
設計の知識と技能で駆動するソフトウェア開発
masuda220
PRO
18
11k
Featured
See All Featured
RailsConf 2023
tenderlove
0
510
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
8
8.2k
It's Worth the Effort
3n
180
27k
Gamification - CAS2011
davidbonilla
76
4.5k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
28
5.9k
GitHub's CSS Performance
jonrohan
1023
450k
Creatively Recalculating Your Daily Design Routine
revolveconf
209
11k
Why Our Code Smells
bkeepers
PRO
330
56k
A designer walks into a library…
pauljervisheath
199
23k
We Have a Design System, Now What?
morganepeng
42
6.7k
The Pragmatic Product Professional
lauravandoore
24
5.7k
VelocityConf: Rendering Performance Case Studies
addyosmani
319
23k
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