Once upon the time,in ancient Greece...
View Slide
Hercules got into toserious troubles...
King Eurystheus orderedHercules to clean upAugeas' stables
The stables was complexand full of mud
As accounted forreal hero, Hercules usednifty trick
He changed flow of ariver and directed it intotwo holes inopposite walls
The task has been solvedin a single day
Unfortunately there’s nosuch heroic attempts inhistory of softwaredevelopment
Instead of heroes, youneed ...
Domain-Driven Designin PHPWojciech SznapkaPHPCon 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 isa way of developingcomplex software ...
... by focusing on coredomain first ...
... modeling andabstracting reality using“building blocks” andprovendesign patterns ...
and delaying technicaldecisions as much aspossible.
It’s all about the domain
You can’t build properlyworking softwarewithout deepdomain knowledge
But, you won’tunderstand the wholedomain at once.It's an iterative process
You needevolving model
It’s crucial to havecommon understandingfrom day one...
… and to speakUbiquitous Languagewith stakeholders andDomain Experts
The model
Good modelact asUbiquitous Language
It reflect domain logic asmuch as possible
It's build using layers* User interface* Application layer* Domain layer* Infrastructure layer
* source: Domain-Driven Design Quickly by InfoQ
User interface presentsand interprets usercommands
Application layercoordinates activities.It's ought to be very thin
Domain layer is theheart of the system,responsible forbusiness logic
Infrastructure layeracts as support,providing persistence,tools, etc.
Let’s speak aboutentities, DDD first classcitizens
Entity represents abusiness being
Entity is not a simpleData Transfer Object ordata container
Therefore avoidanemic entities . Goodentity should providebehavior, besidesidentity and attributes!
Infrastructure layer helpswith persisting entities(using a backing service* of your choice)* http://12factor.net/backing-services
Entities are supported byvalue objects
Value objectsconceptually does notprovide any identity, sothey can be shared
To achieve that, valueobjects need to beimmutable** http://blog.sznapka.pl/immutable-value-objects-in-php
The important fact:value objects aretype hintable
Large graph of entitiescan be difficult to handleconsistently
DDD introduced a termAggregate which iscollection of objects ...
... bound withaggregate rootand hiding underlyingobjects from theexternal world
Aggregates provides acoherent interface tooperate on sub-graph ofthe model
During development ofubiquitous languageyou’ll find that someactions don’t belong toany object
Such situations aresolved withdomain services
Services employ variousentities, value objects,factories, repositories todo their job
When dealing withcomplex objects, theircreation could becomplex and it's good tohide that logic
Well known factorieswill do the trick
Factory hidesinstantiation complexityand enablesinterchangeability inthe future
While factories help withobjects creation, it isequally important toabstract objectsretrieval
Repository designpattern abstracts objectsretrieval from a storage
It’s extremely importantto place alldata access logicin repositories
Infrastructure layerhelps a lot here
It uses your ORM libraryto build specific queriesor use other vendors toobtain objects
More important fact isthat repository* isreplaceable* like the most of DDD building blocks
Modelboundaries
It’s important to drawbold borders inside yoursystem, as it grows andbecomes complex
When differentstakeholders startto confuse you withvocabulary
It's good time to thinkaboutbounded contexts
“Bounded Context is acentral pattern inDomain-Driven Design”** http://martinfowler.com/bliki/BoundedContext.html
It’s quite sure, thatbounded contexts willshare common concepts
Therefore createcontext map to outlinepoints of contactbetween them
Also, distinguishcore domain fromgeneric ones...
Choose proper boundedcontext collaborationmodel
Shared kernel, whentwo teams work closelyon subset of domain
They acts as partners,and access each otherbounded context withcommon code
Customer-Supplier,when upstream teamprovides an API anddownstream teamsconsume it
Customer team caninfluence Supplier tomodify model
Open Host Service,when interface isdefined by widely knownprotocol
It's typical SOA approach
Or:* Partner* Conformist* Separate ways* Anticorruption layer* Published language
Taming the beastA.K.A. Summary
OOP is not enough
DDD is greatfor complex problems
You can pick parts ofDDD and still benefitout of it
You should be aware ofduplication and complexstructures in DDD
DDD doesn't care aboutyour 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 anythingblog.sznapka.pl[email protected]twitter.com/sznapka
Your feedback isimportant!https://joind.in/11844
sznapka
lnit
pospome
loic425
honey32
schroneko
shibe23
yuhta28
ogiwarat
clown0082
tomokusaba
tonkotsuboy_com
beenos
chriscoyier
davidbonilla
moore
thoeni
eileencodes
bcantrill
akmur
colly
brad_frost
swwweet
bermonpainter
samlambert