---
title: '[#phpsrb17]  Andrew Cassell | Domain-driven Design Deconstructed'
source: 'https://youtube.com/watch?v=bgJafJI8mp8'
video_id: 'bgJafJI8mp8'
date: 2026-06-15
duration_sec: 0
---

# [#phpsrb17]  Andrew Cassell | Domain-driven Design Deconstructed

> Source: [(#phpsrb17)  Andrew Cassell | Domain-driven Design Deconstructed](https://youtube.com/watch?v=bgJafJI8mp8)

## Summary

Andrew Cassell introduces Domain-Driven Design (DDD) as a methodology for focusing on core business problems, collaborating with domain experts, and modeling software that is understandable and maintainable. He emphasizes that DDD is not about patterns but about listening, speaking a common language (ubiquitous language), and modeling behavior rather than data.

### Key Points

- **Introduction and Speaker Background** [00:00] — Andrew Cassell, organizer of DC PHP Meetup and developer at Marine Spill Response Corporation, introduces himself and the talk's goal: to help developers become better code craftsmen.
- **What is Domain-Driven Design?** [01:56] — DDD focuses on the core business problem, collaboration with stakeholders, and modeling software that is understandable and maintainable. It relies on object-oriented programming and is meant for complex problems.
- **The Domain and Problem Space** [03:55] — The domain is the problem you're trying to solve. Using a library example, Cassell warns against jumping to technical solutions (like databases or frameworks) before understanding the actual problem.
- **Ubiquitous Language** [07:51] — Ubiquitous language is a shared language between developers and business experts. It puts everyone on the same page and is the ultimate power of DDD. Example: using 'member' instead of 'user' in a library system.
- **Event Storming** [10:49] — Event storming is a process to discover complexity by meeting with domain experts, using stickies to map events, commands, and actors. It helps model behavior, not data.
- **Value Objects** [15:06] — Value objects are immutable, have no identity, and are always in a valid state. Examples: BookTitle, ISBN. They reduce complexity and are a gateway to test-driven development.
- **Entities and Aggregates** [20:36] — Entities have identity and are mutable (e.g., Book, Member). Aggregates are clusters of entities treated as a unit (e.g., Member containing borrowed books). They form transaction boundaries.
- **Domain Events and CQRS** [25:06] — Domain events record important occurrences (e.g., BookWasBorrowed). CQRS separates read and write models. Event sourcing stores changes as events rather than state.
- **Hexagonal Architecture and Framework Decoupling** [30:00] — Hexagonal architecture keeps domain logic independent of frameworks. Controllers are thin; business logic is pure and testable. This improves maintainability and allows frameworks to change without affecting core logic.

### Conclusion

DDD is not a one-size-fits-all solution but a set of practices that, when applied appropriately, lead to more maintainable, testable, and business-aligned software. The key is to start with ubiquitous language and value objects, and only adopt advanced patterns like CQRS and event sourcing for complex problems.

## Transcript

[Music]
okay everyone it's been great getting
the middle of you guys
I'm Andrew Cassell I want to first thank
all the organizers for putting on HP
Serbia fantastic conference I'm so happy
to be here making this horrible noise so
for those of you who don't know me yet
I'm from the United States I live in a
suburb on Washington DC where I'm an
organizer of the DC PHP Meetup and for
the last 10 years almost I've been
writing PHP applications at a company
called the marine spill response
Corporation which is a non-profit that
cleans up oil spills
I work as a part of a small in-house
development team with two other
extremely extremely talented developers
and I like say that because I think this
talk may end up on YouTube so in case
they watch it later but you know we
build PHP applications that organization
uses to respond to expose and natural
disasters so why why are you here today
what why am I here today and I assume
it's because we all want to be better
developers we want to become better code
craftsmen we want to raise the level of
our code we want to become a more mature
developer whether that's go from junior
to senior from senior and on up we want
to have a better understanding of
problems that we're trying to solve we
want to give a better value to your
clients to boxers and your customers the
thing I'm here to talk to you about
today is domain driven design and it's
oftentimes called BBD those are you
don't know it real quick survey who has
heard about domain driven design DVD
good quite a bit I'm not going to change
the slides well I heard
started but good to hear that a lot of
you already know where we're going so
the bulk of the information of this talk
comes from two books they're oftentimes
referred to as the blue book and the red
book I know the color here is a little
messed up blue book by Eric Evans
domain-driven design that's like the old
testament of domain driven design it was
originally released I think in 2004 and
it is the it lays the whole plan out for
domain driven design a little bit later
von Vernon wrote be implementing
swimming driven design that's like the
New Testament and DVD land kind of a
little more practical and how to apply
things but I mean since these two books
have come out there's been many more
people who have applied domain driven
design a lot of things have changed so
there's been more and more books that
have come out with patterns and
principles being one that is a very deep
dive into how to do it and then a lot of
small cliff notes versions so if you're
the kind of person who only goes to
church at Christmas and Easter uses
probably the books for you all the
patterns of Anna talked about today are
not new they've been around for a long
time
these are two famous books on patterns
and software architecture all the talk
information all this stuff from DVD
comes from these books for the most part
and one more thing just to thank Mathias
Varys and Bo Simonson
they've been two big proponents of DVD
and at the HP community
PHP community and without them I
probably wouldn't be doing this okay so
so those of you who have never heard of
domain driven design or maybe you just
read the Wikipedia definition BDD is
about focusing on the core business
problem that you're trying to solve and
developing a valuable collaboration with
other people who hold a stake in the
success of your products and modeling
your software in a way that is both
understandable and maintainable
now DDD is meant to handle really
complicated problems like a
IKEA furniture because what it'll do
it'll break the domain model down into
something that's understandable
and easily maintainable now one of the
things in domain driven design that's
very important is object-oriented
programming if you don't have a good
understanding of object-oriented
programming you're not going to go very
far with it and what I mean
object-oriented programming I don't mean
about cars barking or dogs driving which
we use virtually that usually the first
thing we learn in the object-oriented
program which we refer to
object-oriented programming
refer to the behavior of the objects not
just the methods on them so the first
thing I want to talk about with you guys
is the first word in domain driven
design the domain and when I say domain
I refer to the problem that you're
trying to solve or the problem space for
me my domain is oil spill response and
pencils and chips never like that and I
don't want to have to tell you all about
that so for today's example we're going
to choose something that we all know
which is a library which I've heard
still exist they still have books that
you can take out so let's imagine that
we're going to build software for a
library and you know we're obviously
going to have books in the library so
we're gonna need a book database a table
in our database we're going to have
users so we need a user table and the
user is in the book the book is going to
have the going to have an inventory book
so you're going to have a book inventory
table and then users are going to take
out books we're gonna have a book into
our user link and if you're a symphony
developer out there you're already
thinking oh who's going to be the role
user well that's going to be probably
the librarian or who can be the role
advant well that's the librarian or we
need to solve the problem of logins
sorting 800 auth and they were going to
use like he was saying earlier when he
is no sequel just just stop slow down
our developer reptile brain that we as
soon as we hear a problem we immediately
have a solution before we've heard the
rest of the problem what is actually the
problem that needs solving
so lon not saying that implementation is
not important but choosing the right
framer can make a big difference in a
project but we have to really analyze
the problem that we're trying to solve
before we jump right in and start coding
there's a saying from the jobs to be
done community that people don't want to
buy a quarter inch drill they want a
quarter inch hole people are not paying
you for your software they're paying you
to solve their problem what is the
problem space is your problem actually
worth solving do people just randomly
drop their phone no make sure the
problem you're solve is actually worth
well to solve in the first place
you know reminding ourselves that our
jobs as developers is either to make our
company a pile of money or save our
company a pile of money so maybe writing
our own VI containers writing our own
frameworks or writing your own session
management or logins or password resets
stuff like that is really not important
what we're being paid for is to focus on
the core business problems and I think
that's where a lot of developers need a
lot more help and getting better at that
so when I talk to you about common sense
software development so when I'm talking
about gdb I'm not talking about the
patterns of BDD those those are in the
design patterns books you can learn all
about that and the whole goal here today
is not to add a bunch of complication to
simple problems in one of the first
pages of the red book von Vernon has a
table where he lays out whether or not
you should thinks you should you should
use BDD or not and I think in character
kind of paraphrase that with kiss keep
it simple stupid so if you're doing a
Content site or brochure site don't use
domain driven design if you have a
purely data entry site that's what crud
is for create read update delete don't
use it where maybe functional
programming might work better like a
communication system if you go overboard
with some of the things that I'm going
to tell you about today you end up with
something like this which is called the
fizzbuzz enterprises
which solves the fizzbuzz coding
challenge and I think about 3,000 lines
of code just just kind of summarize so
domain-driven design is not the one true
way to develop software that is
obviously Ruby on Rails now all right so
we talked about you know making good
software what how do we define what is
good software well there's been plenty
of books out there that talked about
factors in software quality or software
requirements I'm going to pick what I
think are the most important five when
it comes to main driven design and
that's correctness testability
usability maintainability and modifiable
modify ability and I'm going to compare
a domain driven design app and a crud
app or is the domain driven design
community calls as a big ball of mud and
it's really just a conglomeration of
code that's all thrown together and
basically hardly ever works so there's a
big push in the domain driven design
community that crud is an anti-pattern
and the reason why that is the case is
that and I agree with this quote here
that a lot of times you know business
people have given up on developers and
developers ability to understand
business problems domain experts as we
call them you know Lord business here
the people that we call product owners
or stakeholders you know someone that
knows the in and out of the business
problem and if that's not you maybe if
you're you know developing something for
other developers you're the you're the
domain expert but when we work with
these people
we're not just trying to deliver them
code we're trying to solve their
problems and to solve their problem
effectively you have to very well
understand their problem so when we talk
to them we need to open our eyes open
our ears and open our brains up and
listen if we open the blue book right
away on page 24 of a 500 page book the
subject ubiquitous language comes up
ubiquitous more common across almost
everywhere you're talking about it so
ubiquitous language would be common
between
developers and the businesspeople
ubiquitous language is really the
ultimate power of BDD it's a shared
language that your development team and
you're doing and experts agree to speak
it puts everyone on the same page and
the power of BDD is understanding the
business mindset the language and the
solutions and understanding how to
implement the business problems in code
so BDD is not about patterns because
tools change we switch frameworks all
the time we switch technology all the
time it's first about listening it's
about speaking a common language and as
we build this common language we're
going to better understand their problem
and how to solve it let's take a quick
example of building that common language
what is the business or you know the
organization that you work for call
they're the people who are using the
software in the case of a library they
probably call them clients customers or
members or employees they probably don't
call them users but yet every one of us
probably have a user table or a user
repository the only people that called
their people using their stuffed users
are developers and drug dealers it's not
that much work to take your code that
has user and use the word member or
employee in it it's plain I'm not sure
if you guys know who David Letterman is
yeah he's like a cranky old Jay Leno he
has the famous thing he does in the
United States it's top 10 list so I'm
going to give you the top two that's in
binary reasons programming is hard and
number one right off the bat gaming
things that is domain driven design one
of the key concepts is against that
ubiquitous language is going to help you
main things whatever you agree with the
business people on that's what you call
it when we look at a crud versus mud app
and compare that to our DDD app we have
users we're going to call them members
something we had like maybe book
inventory repository what's called at
the Library catalogue we have strings
and a crud mud up
let's create objects that represent
these things in our in our code it
becomes much easier to read understand
and I'm not picking on laravel here but
if we take a normal credit app we go
finder sales the object we do somewhere
queries we we try to find you know books
that are related to that user this is
this code if you showed this to a
librarian they would just feel like WTF
it doesn't make any sense it's really
not that much more effort to write code
that is very very readable so instead of
a book repository we have a catalog and
instead of finding the book by maybe
database idea we use something that's
more naturally expressive by one by book
ISBN you know members we have a members
collection instead of a member
repository and instead of setting the
the book relation and attaching it to a
an array inside of the object we have a
borrow function on the member they do
effectively the same thing but in the
naming becomes much easy to understand
because now when you go back to look at
this code five years from now the
cognitive load that's required is so
much less it's like when you learn to
speak a second language like eventually
you stop trying to think of what is the
the word for that so what I learned
German the first time you you know you
learn library it's bibliothèque but you
have to think what is the German word
for library eventually you get faster
and faster you don't think like that
anymore you just start to speak in the
language and that's what this does
eliminates that translation layer in
your brain you don't have to try to
guess you don't have to try to guess
what this code is doing this kind of
code tells you what it's doing and it
offers great encapsulation now I'm not
saying you break the law of Demeter or
don't follow solid principles but code
like this is easier to understand and
easier to maintain going forward
now if you've settled on a language with
your your business people and you're
trying to form that ubiquitous language
choose the words that they use for the
most part that's going to be much
year to go with what they want but you
know any one of these is fine there's no
right or wrong it's really dependent on
the project you're working on and I'm
going to guess as developers if you're
doing be hot testing you're already
doing this a lot you're already putting
these verbs in your be hot test so right
there is your function names right you
just haven't seen it the whole time kind
of summarize this thought here I think
is a great quote but the important part
is here at the bottom it says programs
must be written for people to read and
only incidentally for machines to
execute because software is incredibly
difficult to maintain just because it's
malleable and easily changed making
something that is easy to read and easy
to understand we come back to it later
is probably the most important job we
have as programmers so if I'm comparing
the DDD version and the ball of mud
proud version I'm going to give DDD a
checkmark in the correctness column
because it's much easier to make the
software correct because you can model
it properly and follow languages the
business uses and directly translate the
businesses problems in the language in
the code
another topic that's in the kind of in
the ubiquitous language part of this is
something called natural identification
so as developers we often rely on
primary keys and UID you you IDs the
business does not think like that a lot
of things that were you're dealing with
like let's say this is our library
example I already have an ID they have
an ISBN number we should be using the
numbers that the business you know
relies on it already has an account ID
use the account ID that's already unique
things like that when we're modeling
this ubiquitous language don't pretend
it's like the 1800s when you're doing
this model if you're doing it like say
an online ticketing system don't pretend
that people are coming up to a counter
and buying a ticket no it's ubiquitous
in the sense that the technology
influences the language just as much as
the business problems do it's a two-way
street because you know as businesses
evolved obviously you're going to be
changing a software to match the
evolving business and as the business
involves your code needs to evolve with
it and the language needs to evolve with
the code as well okay so if you're in a
large organization and you're supporting
many teams throughout your company
there's one more thing I want to tell
you about ubiquitous language and that's
that
when I say ubiquitous it's not
ubiquitous across the entire universe so
if you have a marketing department in a
finance department or sales and
production you know they make all those
users or clients or members different
things and throughout the different
parts of your system you may want to
create separate objects in order to keep
the parts of the code for that part of
the system separate from the others and
in one part of the system you might call
that object a lead or payee or maybe you
know the production team only cares that
they're shipping to people so we call it
a ship - again it's just about naming
and keeping things separate because one
of the problems that large code bases
can end up in is what they call the big
ball of mud oftentimes that's referred
to as spaghetti code or shantytown code
if you don't keep things separate and
you start calling you know methods all
over the place you'll have
so in our library example we're going to
set up three bounded contexts and that's
bounded context is that separation of
concerns within a larger application so
we'll have a billing section alone
section which is lending out books in a
catalog section and we're going to avoid
you know calling methods and putting
objects all over the place in our in our
system because as things grow and we
would try to make an update to the
catalog system if that's directly
depending on the billing system we're
going to have problems maintaining that
so what we're going to do when we cross
these bounded context in these separate
areas is pass messages and the messages
we're going to be passing for the most
private call domain events and I'll get
into domain events in a little bit here
but the main thing here is that you're
passing messages between it whether
that's an event or you know maybe it's a
microservices in your passing HTTP or
less
either way try to keep your bounded
context and parts of your system as
separate as possible as decoupled as
possible can't stress that enough
all right so how do we build this
ubiquitous language well our goal is to
discover complexity on early on and the
best process I found for that is called
events storming now you have to follow
this process exactly no you don't have
to especially if you're already an
expert in the domain probably don't need
to go through this exercise but I want
to show you this because I think it's
the correct manner to think about
solving software so the first thing you
need to do is actually meet with the
people who have the problem that you're
trying to solve the goal of for essence
developers is to fully understand the
problem a bunch of tickets in JIRA is
not an understanding of a problem what
we have to do as developers is get out
from behind our cushy standing desks
that go up and down and get out in the
field
now UX professionals call this
ethnographic ethnographic research in
the library example go to the library
see that they have a terrible windows 98
computer running ie6 that's going to
influence how you write your software so
what I'm advocating is that developers
should work directly with stakeholders
we're going to ask a lot of questions
we're
ask a lot of lies they call it the five
why's so if the librarian says oh we
need people to borrow books well you're
going to ask why well because that's how
our business works and you're gonna ask
why and keep asking why and why and why
usually when you get to the fifth why
usually find out what the actual problem
is when you meet with these people this
is what I call you guys know the
comedian George Carlin is the seven
dirty words which I'm not going to say
is this might end up on YouTube but when
you're meeting with a domain expert do
not use these words they don't
understand what an interface in an
abstract class are what we're trying to
do here is actually figure out how we're
going to address the problem get some
Sharpie markers or some you know a
whiteboard and some markers don't jump
right out of the computer we use
computers you know eight hours a day
maybe
compared to the people that are you know
we're working with we're probably better
at technology we're faster we can scroll
through things faster I was in a meeting
once with one of the guys that I work
with and he's like he said my eyes are
rolling back in my head you're scrolling
through stuff so fast and you know that
was one of the times I realized that you
know maybe we're going about this wrong
and that a you know a low fidelity
approach like markers or you know
writing is approachable to anyone
whether they have any technical
expertise or not almost anybody can grab
a marker and draw something now the
events storming really is about getting
a huge space and putting a bunch of
stickies up and the goal here is to try
to tell a story of how the software's
going to work we're going to start with
the events that are in her system in the
library example a book was borrowed and
that a book was returned and the reason
we're doing this is we're trying to
avoid data modeling we're trying to
we're trying to model the behavior that
is in the system not the data eventually
going to start building out more and
more of a larger you know diagram you're
going to have the people involved the
members that librarians and stuff like
that those are called actors in events
storming and you're going to be creating
commands that go in the system like
borrow book there's the blue
there and you know as things get larger
and larger you'll you'll start to figure
out the areas that you want to split off
like maybe the billing context here the
billing system really doesn't need to
know much about the book borrowing a
book landing system we can use the
messages or events to pass stuff to that
so we can keep those two separate you
know if you look at this and maybe an
event causes something to happen in that
system so an event will have an event
listener which will cause a command
which you know causes to happen in the
other system it's kind of going through
the rest of it I mean you can flesh out
you know your whole story for your
software eventually you might end up
with this this giant diagram but this is
very valuable because you can refer to
this later when you want to know how
does our software work like if you're
trying to read code that may not be
entirely obvious especially when things
start firing off events and sending
messages that becomes kind of decoupled
and very separate hard to understand
diagrams like this can be very valuable
so I'm going to give DVD a double check
mark in the practice called because you
know I think the process of building
your solution is starting with the
problem and figuring out what is you
know really the thing that you need to
do and using a behavior model not a data
model Martin Fowler he says that doing
that opposed do the transaction scripts
that were used to writing is the essence
of a paradigm shift in object-oriented
programming so if we want to model this
the thing that the DVD people call
domain objects these are the various
things that are going to be in our code
these are value objects entities
aggregates and domain events these are
primary four types
the first one is value of objects those
are the smallest of things in your
system and those are going to be
immutable they have no identity things
in our library example would be a book
title and amount paid an ISBN number
very small things
now contrasting that with some of the
larger things entities value objects
have no state they're immutable and
there's not really much to them an
entity like a book or a
Berrien or an invoice has more about
it's identifiable in the system it's
mutable things change you know
librarians change their name it has a
lifecycle librarians are higher than
fired enemies will contain the value
objects like a book entity will have a
book title or an ISBN number it'll
contain those value objects and an
aggregate is just a kind of a fancy
entity it contains other entities so a
member may have many books in its
possession things like that so let's
start with the value objects there's a
smallest and easiest to understand look
at some of these things in the library
example a book title a Dewey Decimal
number date borrowed there's are going
to become objects in our code directly
so we have a book title class a Dewey
Decimal number class and the reason we
do this is not just static typing so
we're not just doing this for the sake
of type int a everywhere there's plenty
of research that will tell you
statically typed languages don't
actually help that much when producing
bug-free code the goal here is that
we're going to be reducing complexity
introducing checking throughout the
system now you have an extra mutable you
know and PHP objects are passed by
reference so by making our objects
immutable we avoid with I consider the
spooky action at a distance and objects
where if you pass an object you're not
guaranteed that that function that you
called is not going to change that
object so one of the things that is
probably the most important aspect of
domain driven design is that almost
everything is always in a valid state
that starts with valid value objects
value objects are like eggs
they're the very thin shell around your
app that is going to solve as many
problems as possible at the very edge of
your domain layer so the earlier you can
handle a problem the less you have to be
defensive throughout the entire
application value objects are also a
gateway drug to test your in development
if you're not doing test-driven
development value objects are a great
way to get started doing test-driven
development hash tag my tests don't pass
how do we implement value objects well
they're just plain old PHP objects or
popo's as they're called we declare all
the class properties as private we have
no setters there's no way to change the
data that's inside on a value object
they don't reference anything that is
changeable like a mutable object and we
throw exceptions on constructors so they
can never be an invalid state let's live
it a simple example like the book title
business rules for a book title is that
a book title cannot be empty cannot be
an empty string we have to have a book
title that exists let's start with our
test the first thing we can do is start
a test and to make sure that you know we
put in a book title we get a book title
back out saying value comes out and the
second one will test that you know if I
put in an empty book title we expect an
exception we run our test the class
doesn't exist yet let's go create it
first thing we do is just do a simple
almost like a DTO we put the title
string in and we get it back out that
passes our first test that was easy the
next thing we do is we throw an
exception the constructor the title is
empty also very simple and that passes
our test light is green tests are clean
we can move on let's run through another
example date borrowing now to borrow a
book the the date has to be a valid date
that's going to be pretty much handled
by the date immutable class but this
library system we're just you know
developing developing it today well I
know that in my system no date can be
before May 28th 2017 I can put that
check in here and if somebody
fat-fingers the number and put something
in wrong I can in throw an exception
because there's no way that somebody
could borrow the book before or things
like dates way in the future I've had
just have many times or somebody types
in the wrong number and it ends up with
a year of nine thousand and nine that's
obviously not the case we can protect
those kinds of things in our system so
insert another value object that would
be in our system like renewals remaining
so how many times can you renew a book
to the library again we're protecting
this class in the constructor by
throwing an exception if it is in a
valid state the count goes below zero
we're going to throw the
exception now we can put behavior on our
value objects and they return a new
value object remember I said there's
it's not mutable so we can't just
decrement the count when the decrement
function is call it returns a new object
and when you return the new object you
can guarantee that it's in a valid state
because the constructor is run so you
really don't have to look cool check is
you know they're renewals remaining
Jesus user have to one your renewals
remaining you can just call the
decrement function and then catch the
exception you don't have to worry about
it the logic changes it's on renewables
and things like that it eliminates a lot
of checking and a lot of if checks
throughout your entire code base let's
go to one more example hopefully this
will you know just to kind of solidify
this you can use value objects that are
composites of other value objects so
like a loan period for a book start date
and end date you can pass the value
objects that we created earlier in the
constructor and guess what you have to
don't have to do any checking I know
that if it's a date borrowed it's a
valid date I know if it's at they do
it's a valid date renewals remaining I
know they have renewals remaining
because it couldn't be a negative one
here it's already been validated it's at
least a zero or one then I do a little
bit of a check here to make sure that
you know the start date isn't before the
NBA tour after the end date or you know
whatever vice-versa
and if that's not a valid condition we
throw an exception so now I can pretend
I can depend on this loan period always
being in a valid state throughout my
entire application and I can do things
like math on it stuff like that if I
want to extend the loan by two weeks I
can write a little simple function
extend by two weeks and it you know
takes the date borrowed adds two weeks
to the date that it's due and return I
mentioned earlier that you know your
behavior that's on the renewals
remaining decrement function that's
going to protect this so if somebody
doesn't have any renewals left you don't
have to check other renewals remaining
first before we extend the loan by two
weeks it's automatic I would throw an
exception you catch the exception say oh
this person can't renew this it's a
completely different way of thinking
about doing code so in gdb you know we
have things like book title
condition ISBN and cred mud most people
are just using strings dewey decimal
number would be an example in a library
probably just a float so for DVD verses
the ball of mud crud the testability is
much much higher the maintainability is
a lot higher and i think your code is
far less brittle if you're using value
objects if you don't take any of the
advice I give you this talk using value
objects in places that it matters will
make a big difference in your code
because you know let's face it we don't
all test everything so what are entities
well entities like I said is anything in
your system that is going to change over
time like a librarian or a library may
change his name a book a book could you
know get destroyed so it might have
state in the sense that you're going to
track it a lifecycle entities in are
identifiable they have an ID like the
ISBN number for a book may be a member
ID or an account ID they have state in
their mutable you can change them but
again just like the value objects we're
going to try to keep your entities never
in an invalid state so everything is
going to be always valid throughout the
entire system they're going to again
operate on those value objects we're
going to try to avoid putting security
and permission checks inside of our
entities and the last thing is going to
try to do is make them storage agnostic
and that can get a little bit
complicated but usually most people use
doctrine annotations to do that let's
look at an example of an entity
hopefully you guys can see that in the
back but if we have our book class you
can see just like that composite value
object all we do is pass the other value
of the kind of a constructor and we no
longer have to validate that the book
title is not empty and the ISBN number
is valid in the book condition is valid
and the last thing is we just generate a
UUID inside of the entity to create the
unique ID for that entity if you guys
are using like active record pattern or
MS that you know use data arrays things
like that you're going to be able to by
passing those objects into the
constructor you avoid that check you
don't have to constantly have this you
know check for empty every everywhere
throughout your system the getters on
these entities are going to return at
value objects so if you have a get book
condition a good book title those should
return the value objects let's look an
example of how to store these in a
relational database using doctoring so
we had the constructor for the book
which has the book title ISBN and book
and it's book condition what most people
end up doing in PHP is using doctrine
annotations or the doc doctrine why yeah
a file or other ways of setting up
doctrine but you're just going to store
those you know in the database now the
easiest way to go through doctrine is
the store two strings doctrine does have
something that's called embeddable which
lets you actually store the value
objects directly but that can get a
little bit messy when it goes a little
bit too far so i recommend like casting
all these variables to string and then
getting that back out but that's it's
not that bad I'm sorry but the biggest
thing I want to bring to you from
ubiquitous language and to your energies
is that senators are bad okay we don't
want to have set-set-set-set everywhere
I'm not going to pick on propell is
there a fine oral but the problem with
using an ORM is we say new book set
title set price you know set author all
this stuff and this kind of code becomes
hard to maintain over time because at
what point is the book in a valid state
when we say the new book it's not valid
yet because it doesn't have a title
where we haven't set the price yet it's
not till all the way down in the code
where you call save that makes it
incredibly difficult to test the only
thing here that's really protecting this
possibility are the database constraints
and it's really hard to do database
constraints like a date not after May
28th 3007 it becomes incredibly
difficult to try and do or impossible
again and put behavior on our entities
that actually makes sense for the domain
so if a librarian needs to look at a
book and say that this book has been
damaged maybe we have a degrade function
for
creating the condition of the book or
damage function that marks that has
damaged again don't don't use setters
because that just loses the ubiquitous
language or the understanding that you
have in your domain aggregates so I
mentioned aggregates are a fancy kind of
entity they manage child entities and
they form a transaction boundary in a
database examples of an aggregate in the
library example would be a member
because they're going to contain books
they are going to have books in their
possession if you have invoices in your
system that's a great example of an
aggregate because an invoice contains
line items things that are entities that
could change on their own that are then
contained by the aggregate so in our
aggregates we're going to take language
directly from our domains if you look at
the top left we have the member
borrowing a book so pretty easily we're
going to have a borrow function where
you pass a book to it and just for now
let's say that it just puts the book in
the array and using like you've
mentioned earlier horrible doctrine
annotation that can automatically be
stored in the database if you want to
put some logic in your aggregates and
your entities that's that's great you
know if we want to limit the number of
books that somebody can borrow to five
we can build that right here in the edit
e we don't have to do the checking
outside so if somebody goes to borrow a
book and they already have five books
borrowed which are an exception and
catch the exception if the logic behind
borrowing and how the limit stuff like
that maybe this isn't the greatest
example but if that became complex feel
free to use a specification special
education pattern is a well-known
pattern and here you can guard for these
things and try to protect that by using
external classes that you bring in and
the reason you do this is for testing
it's a lot easier to test the book
borrowing limit specifications by itself
then trying to test it while you're
trying to test the entity and I
mentioned that entities are aggregate
roots form a transaction boundary that
is really just you know and when it
comes to database if you're going to
store a member you make changes to a
member everything that goes along with
that member is going to be stored in one
transact
if you have another aggregate it's
another member that's going to be maybe
a separate transaction if it works out
like that but the whole idea is of these
these aggregates are atomic and that
they're consistent all the time never
invalid state so you know we talked
about value objects and aggregates and
entities in all this ubiquitous language
what this boils down to is not only
better code more easily you know easily
read easier to maintain I think it's
also going to improve user interfaces
because if you're doing crud apps a lot
of times when you design a crud app you
follow the cred patterns where you're
creating adding creating and reading and
updating deleting so you end up with a
table of things like borrowed books and
you have edit and delete now when a
librarian comes to your software here to
use this she's not thinking I'm going to
come to the borrowed books
part and delete a book it's it's not
returning a book is not deleting a book
or editing a record for the loan date
you know this ubiquitous language and
this event storming you know figuring
out this language kind of forces you
down
having buttons that match the functions
that are on your objects so you know if
you have a borrow function on the member
you're probably going to have a button
that says borrow a book and this is
called a task-based interface and it is
a far better way to design user
interfaces compared to what they call
this which is the programmers interface
which is understandable only to
programmers so I'm going to give DDD a
check and a usability column because I
think it's makes software that is both
easier to use so people using it and for
the developers to develop now one of the
things I haven't mentioned yet that I
think is very important on every app is
security and domain-driven design when
they talk about security they talk about
taking a layered approach and when they
say layer they don't mean the
traditional you know layers going down
we talk about this fancy term called
hexagonal architecture and what it is is
it's kind of a fancy way of doing
layered architecture it's highly
dependent on the dependency inversion
principle that high-level modules should
not depend on lower-level modules and
that both should depend on
so when you're moving between layers in
your system you're using abstractions
and interfaces so your object literature
down your business domain have no idea
how to render themselves that everything
is patched up through an interface so
the goal here is not to avoid tying
everything together to keep things be
coupled to keep them loosely coupled if
you notice this red layer on the outside
is very thin and there's a reason for
that because frameworks should not be
part of your core logic they are
something that is separate code
maintenance becomes very difficult now
if you've watched the office space movie
and you realize at some point you just
want to do construction work because
maintaining a legacy code base and cud
and it's all tied to the framework and
you have to do an update makes you when
I just quit you know I've I'm 33 years
old and hopefully I have another 33
years of development in front of me I
have no reason to you know assume that
I'm going to stop but I feel like you
know I spent I spent the first few years
as a developer digging my own grave
as I was chugging out crud code I had
built it you know we our team built a
large application and we're now trying
to support and please take my advice and
try to develop much more maintainable
code than I did because you know it
becomes a huge burden because your
frameworks you know are on a release
schedule of twice a year say for
symphony or laravel you know whatever
they feel like and I guess but you know
that framework is changing all the time
and you don't want to have your domain
logic tied to that framework and have to
change your domain logic with it every
time so you know important to keep that
separation you know I'm hoping that the
domain logic I'm writing today could
last 10 20 years I'm sure we're going to
change frameworks five six times in that
amount of time just technologies go so
fast I want to mention two great talks
by Matias Farias
and uncle Bob Martin first decoupling
the model from the frameworks gave it
leaner con that's on YouTube and then
Ruby Midwest architecture the last years
by Uncle Bob
to watch those talks they're fantastic
so many DVD practitioners recommend very
thin controllers pad soft commands to
command bios and application services
I'll get to those in a minute
but when I want to mention real quickly
here is that following solid if you have
heard the solid principles and you know
having good clean code and depending its
dependency inversion things like that
that are very important that really
really matters in the center section in
your domain your business logic it's
important to keep that pure and that
separate from the framework and very
well architected the outside edge the
framework code your controllers I think
you save a lot of time by you know
treating it like a wild wild west just
get the job done in the controllers but
that relies on solid well tested
business logic you'll be able to move
much faster so you know I think the
hexagonal architecture and qicang accord
with the domain business logic separate
from the frameworks is a much better way
to maintain software going forward so
when you give the check mark and
maintainability so if you want to look
at you know how do we keep this software
modifiable one of the best ways I know
is using debate events and domaine
events are part of the core domain in
that center section in that exokernel
architecture these happened in the past
they're probably important enough to
record so we're going to we're going to
persist those to the database they're
important enough to other parts of the
system so we going to pass them around
my messages they are immutable value
objects just like everything else with
the other value knowledge that I talked
about earlier they do not contain
entities or other mutable objects just
like the other valuable objects and if
you want you can create them in entity
and I'll show you how to do that alright
so let's look at the first one first
event here at the bottom on the Left
book was borrowed we use that as an
example of an event so like I mentioned
an event is a value object there very
simple we have the value objects pass in
a constructor we know everything is
valid here there's no checking to do now
it's the name of it book was borrowed
that's meant because it was in the past
tense
obviously you don't have an event until
somebody does something in a system and
when you're publishing it it's already
having the pass
there's no setters on these again
they're immutable and if you're going to
persist this there's one little thing
you have to do and that's just add an ID
to it and then you can use your docket
annotations things like that if you're
not going to persist it you don't need
an ID now let's take a little bit more
complex example here this is our flow
chart for the book lending context and
let's assume that somebody has damaged a
book and we're going to remove it from
circulation so that's that bottom event
we're going to create an event called
damaged book was removed from
circulation and bring that up a little
bit bigger now I know this looks like is
a really big long German word but it
describes what is happening what has
happened in the past don't be afraid of
long class names if you if you need more
words to describe something use more
words if you need less words these less
words but I can't overemphasize enough
that if you just call this you know
damage book you don't know what is you
know actually happened you know as the
book damaged we move be very very
specific when you're naming your meds so
if we're in the you know place we're
going to charge a fine for that number
remember I mentioned having separate
bound in context or alone system and our
billing system we're going to put in
what's called a listener or a subscriber
in that partion of the code will listen
for that event to be published and you
know we're going to have very ubiquitous
language sounding functions like charge
fine on member and then we're going to
publish the if that member was fined if
you're using Doc's from an entity
manager you're going to flush your
domain model to the database before you
fire the event we're using to do that is
so other things in the system can again
read that data off the database but more
importantly if you ever decide to change
your architecture later and because your
system grows and you need to move from
your events to being immediately
published to a queue you no longer have
to worry that your data is not being
persisted before the event is fired off
to the queue so this last line of this
function here is what we're gonna attack
next is publishing the event inside the
listeners the
we do something which is called
recording events or event recorder
basically the the object is going to be
responsible for tracking the events that
happen inside we can easily fire the
events inside of the entities and I use
a trait throughout the system called a
vent recorder and all that does is track
an array of events that happened the
object as the object is mutated so by
doing this we don't decoupled the fact
that member entity is creating these
events very easy to see that if you look
at the member class the events that are
generated or inside that entity so on
the outside this was a controller or a
listener or whatever your last line of
everything is just going to be whatever
the entity is get recorded event that's
just like a good way of knowing that
everything is working and everything has
been published throughout the entire
system so using an event using something
like that instead of calling functions
throughout different parts of the system
I think makes your code much more
modifiable I give the check to that now
when I cover two topics in domain driven
design that somehow I've gotten really
really mishmash and DVD but I don't if
you go and read stuff about DVD you're
going to immediately see these two
things and that's command query
responses segregation secure us any
other one is event sourcing now CQRS is
it sounds like a complicated concept
concept but it's it's not really that
complicated what we're going to do is
we're going to take our arc software and
our code when we split it in two
sections one for rights and one for
reads and when we see like the rights
ray is really talking about models so
we're in have a write model and that was
the entity as an aggregate of things
like that that I've been showing you and
the read model and the read model is
probably maybe just repositories and
arrays it really doesn't matter do that
however you want because that's mostly
going to be used for reporting and views
and things like that that don't really
aren't really business logic or are not
core to the domain the read models
probably change much more frequently so
I change by having your code split
between a domain model on the right side
and a read model on the read side as the
read model changes more frequently you
don't have to make changes as a main
model and more complicated business
logic
Yeah right was the domain model so how
it is like CQRS work just kind of like
as a high level thing well if you're
used to having controllers that do
everything we're in a split kind of
where everything happens into a separate
section called a command bus and the
command bus is going to have many
handlers so if you used to event
publishing it's like having an event
publisher and many things listening to
it that that's really what it's going to
happen so as a request comes in the
controller all it has to do is figure
out that request becomes this command so
you know if you're using Symphony and
you've defined your route your
controller method becomes like one or
two lines you're just figuring out okay
this is a member or a book route all I
have to do is generate a book was
borrowed command and fire that to the
command bus so our command is again
another value object an immutable value
object just like the other ones there's
no centers on this and they're very very
simple to create usually it's just IDs
not too worried about entities at this
point so your controllers become super
super spin very very easy to modify
so that controller figures out the
command it creates that object and it
publishes it to the command block and
the command bus all it has to do is
figure out which command handle or do I
pass at you so let's lay passes to that
now usually what happens is that a
command figures out a response and maybe
that gets piped up to the controller but
if you're already at this point of doing
secure arrests you're probably doing
something that's very complex so that
might not be the case maybe you're doing
Ajax polling or something like that so
you know don't say that every command
hailer is going to return a response if
not answer the gate the goal here is to
make sure that our controllers are super
super thin so that one line controller
is going to be very very important when
I mentioned that we're trying to
separate our code from our framework
because now when Simpson your laravel
changes a way to do routing with
controllers it's it's very easier just
moving one line to another function call
I'll put the slides up on line but on a
put a link to this article here it's a
great description of CTS using human
command bus but I want to caution you
that not every problem just like I was
mentioning earlier in the beginning to
talk not every problem needs CQRS and
event sourcing an event by my command by
this is a diagram I made
work trying to describe what this
architecture was going to look like and
it got kind of complex I didn't think it
would at first but yeah there's a lot of
complexity a lot of classes to
implementing this so you know be
cognizant of that so really for
complicated problems the last thing I
want to talk about in DDD is event
sourcing now there's anybody here play
chess a couple people
all right so chess matches can be
described by a list of moves you can
read if you know how to read the
notation you can replay a chess match
the almost ending chess match that has
happened in the last couple hundred
years is available in this notation if
you go to your bank they're not tracking
your balance at each you know by setting
your balance in a database table to
tracking every transaction throughout
the system that's how your balance is
calculated as developers we're used to
get no we use get and if you know the
internals of get it's not storing every
copy of every file you have it's during
owning the changes that's the gist of it
event sourcing is that we're only going
to change store the changes that happen
entities over time we're not going to
store the whole estate of the entity
what are the advantages of using event
sourcing versus using normal relational
models now he mentioned earlier the
object-relational impedance mismatch you
basically can avoid that through event
sourcing you avoid writing a lot of data
mappers which a lot of developers hate
reduces the table count so if you have
members and/or sleep maybe the invoice
example is easier if you had invoices
and line items and shipping addresses
and taxes and things like that your
story you end up basically down to two
tables one is an invoice like ID and the
other table is all of your events so
we're not going to store the the project
properties of the object that database
we're going to store the events or in
persist them an append-only storage that
becomes you know quite easy to do it's
basically an array in event so if you
create an object when you push in array
an event but when we have our methods
that we're talking about earlier earlier
like borrow like the ubiquitous language
method of borrow a book all that becomes
is applying the ascent to the object so
if you put the book was borrowed event
in the history of that object if you
were to replay that history of that
object you would not you would know that
that book was borrowed so it's a way to
be couple your entity is even further
from the storage so it can be an
agitation to that again just like the
seeker s it's a little bit more
complicated so I don't advise it for
every project there's a couple of
libraries that will help you do event
sourcing easier and I'll put those there
on the slide sequence iam people learn
more you know all the books are out
there there's a great group of guys that
did it and ladies that did a dev book
club they went to the red book chapter
by chapter and talked about it a couple
of great podcasts that podcast will
stack Radio Elephant Room I'll talk
about domain-driven design the
domain-driven design conference from
Europe posts all of their videos and
talks online at least most of them and
they're all fantastic to watch if you
want more of a workshop there's an ID DD
workshop which is done by the guy who
authored the red book there's a github
repository that's a state of the union
that you know great things are happening
in GED and there's a Google Group out
there that is absolutely fantastic
there's tons of information on there but
all those things are getting in the
slides you guys can go find them I want
to leave you with one more thing in
domain-driven design and if you've ever
heard of this it's called the manifesto
for agile software development it's at
agile manifesto org what I mean agile I
don't mean you're a drow I mean actual
make software that has developed in an
agile manner meaning it's responding to
change they have a couple of you know
key tenets that they promote and they
say individuals and interactions now are
over processes and tools for me for
domain driven design that means meeting
with domain experts in building a
liquidus language not trying to do out
you have all diagrams and things like
that working software the need we don't
need documentation and software is easy
to read just like that code that I
showed you earlier you don't have to try
to decipher it is easy to read customer
collaboration again that's building that
ubiquitous language and not trying to
you know do spec after spec at respect
with respect to try to find your
software build that
event storming session build with the
software supposed to do that becomes
your spec and responding to change
that's easily modifiable code code that
is a couple from our frameworks code
that uses the main events that passes
messages and is easy to couple you know
I think following some of the practices
of DDD if they don't do everything that
I talked about today will make your
software much more agile you'll be much
more successful and hopefully make way
more money so the talk is on joined in
if you'd like to rate it I copied some
of these topics I didn't really leave
time for questions but I am happy to
answer questions later on the lobby or
over a beer so thank you
[Applause]
[Music]
[Applause]
[Music]