---
title: 'Domain-Driven Design in Laravel: My Interpretation with Examples'
source: 'https://youtube.com/watch?v=92uaRrY_1qw'
video_id: '92uaRrY_1qw'
date: 2026-06-14
duration_sec: 1186
---

# Domain-Driven Design in Laravel: My Interpretation with Examples

> Source: [Domain-Driven Design in Laravel: My Interpretation with Examples](https://youtube.com/watch?v=92uaRrY_1qw)

## Summary

This video explains the logic behind Domain-Driven Design (DDD) using Laravel examples. It emphasizes that DDD is a concept independent of Laravel or PHP, focusing on business rules and domain logic first. The speaker demonstrates how to move validation from controllers to reusable services and ultimately to domain entities, highlighting the benefits for larger projects.

### Key Points

- **Introduction to DDD** [0:00] — DDD is a concept not tied to Laravel or PHP; it's a philosophy centered on business rules and domain logic.
- **DDD Definition** [0:28] — DDD is an approach to software development that focuses on the processes and rules of a domain, based on a 2003 book.
- **Laravel vs DDD Thinking** [1:41] — Laravel thinking starts with controllers, routes, and Eloquent models, while DDD starts with domain logic and entities.
- **Problem with Duplicate Validation** [2:46] — Having separate form requests for store and update leads to duplicated validation rules, which is problematic in large projects.
- **Unified Validation Approach** [5:51] — Using a single form request with conditions for store/update reduces duplication and centralizes logic.
- **Moving Logic to Service Classes** [6:50] — Form requests are tied to HTTP; for reusability across queues, commands, and tests, validation should be in service classes.
- **DDD Entities** [10:20] — In DDD, business rules are encapsulated in domain entities (PHP classes, not Eloquent models), which are designed first.
- **Ubiquitous Language** [14:00] — DDD promotes a common language between developers and business stakeholders, making the code understandable by all parties.
- **DDD Overkill for Small Projects** [15:00] — DDD is often overkill for small projects but beneficial for large projects with many entities and developers.
- **DDD Opens Career Opportunities** [16:12] — Understanding DDD can lead to jobs at bigger companies and with other technologies, as it's a sought-after skill.

### Conclusion

DDD is a powerful approach for large, complex projects, emphasizing business logic first and a ubiquitous language. While it may seem like overkill for small projects, learning DDD can improve code maintainability and open career opportunities.

## Transcript

Hello guys, today I want to explain the
logic behind domain driven design with
examples of Laravel. And the term domain
driven design is not Laravel is not
about PHP. It's way outside of the
framework and programming language. It's
a term. It's a concept. And this is the
definition I found best on Reddit. Also,
another definition is by Martin Fowler.
It comes from 2020, but based on a book
from 2003. So, it's not a new concept.
its approach to software development
that centers on processes and rules of a
domain. What does that actually mean? So
for the last month or so I was trying to
explore experiment asking AI as well
because there are a lot of
interpretations of DDD specifically in
Laravel. You may find different examples
open source and tutorials with different
folder structure, different naming of
things, different approaches. So I was
thinking how to explain it and kind of
summarize it for people in simple
example because domain driven design is
not for simple projects. So how to
dissect it down and I think I succeeded
in a new course about Laravel modules
and DDD. So there is a oneh hour section
about domain driven design and in this
video I'll try to summarize it even more
for you with simple example in fact
three examples. We will go from simple
Laravel controller and validation and go
a few levels deep where that validation
should be stored until in the second
part of this video. I hope it would make
sense why DDD may be beneficial and what
problem it solves in projects and why it
is different from Laravel first
thinking. So in Laravel we first think
with controllers, routes, eloquent
models, migrations, form requests and
stuff like that. In DDD thinking is
totally different and let me explain
that in this video. So if we take a look
at a typical DDD structure inside of
Laravel application this is way outside
of Laravel terms. So we have application
with DTO's queries commands and stuff
like that. Then we have domain with
entities and some of the folders and the
names may be familiar to you in Laravel.
And then only on some layer we get to
controllers and eloquent models and
familiar structure with Laravel. And at
first it may look like a total overkill
to you, total overengineering. And in
most cases in fact it is. But let me try
to explain the way of thinking why that
structure may be beneficial if you start
with very small Laravel typical
controller. So let's start with a simple
example which probably everyone will be
familiar with. a typical Laravel
controller with validation in form
request and in store and update methods.
You have different form request classes
because the rules are a little bit
different for store and update and
inside of that store post request we
have rules for title content and slug in
the store request and then in the update
request the only difference is unique
which should ignore the current post ID
being updated. I think majority of
Laravel developers have done something
like that in their career. And this
approach is okay. It works. There's
nothing really wrong with that. You
could even potentially reuse those form
requests in another controller like API
controller. So I created specifically
postcontroller API with similar store
and update methods reusing the same form
request because form requests are in app
http requests. They are not related to
API or admin or web specifically. So
they are reusable which is great. But
the main problem with this approach is
that the logic of validation is in two
separate places. So imagine some
colleague from your team asks you could
you check what is the length the max
length of the post currently in our
system. Where do you go to check that?
You have store post request here and you
can find that the validation is max 150
but you need to double check that with
update form request is it the same. So
you go to update post request and double
check that yeah it is 150. Of course you
can go to just create form request and
not check update form request. But then
you need to trust that no one made a
typo and mistake and those strings are
actually identical in two classes.
Similarly, for example, what if some
manager asks you to make content
optional? For example, when adding a
post, the title and the slug are
required because we're planning the
post, but the content could be written
later, right? So then that required
should be changed to optional. But then
you need to do that in two places in
update post request and install post
request twice. And of course, this is
easy if that is the code you wrote. So
you remember that is in two places or if
the code base is not that big. So you
have like five CRUDs typical simple blog
and then you remember everything or at
least you know that the logic is in
separate form requests. But imagine
you're working with a project with 50
plus cruds with 10 or 20 developers and
you are asked the same questions about
validation for a module for a part of
application which you haven't seen
before. So you're working on internal
CRM for example and you don't touch the
blog ever in your day-to-day life but
someone from the team asks you to
quickly check that code. So then if the
logic is in two places, you may totally
miss one of those places or at least you
need to double check and be double
accurate and of course cover everything
with tests to not break anything. But
just the principle of logic in two
places then for bigger projects is a bad
practice. So a better approach to unify
the validation rules would be one form
request class you could call it post
request and then you provide the rules
and then add conditions depending on
where that request comes from from store
or update. So you have the route you can
check this also you can check for
example if there are other conditions
like for admin controller you have those
validation rules which do not appear in
the API for example. So then you add if
conditions, you may create private
methods here, but basically all the
logic to create or update a post is in
one file. Now don't get me wrong, the
separate files approach again is not a
bad thing for smaller projects. If you
remember that those are two files, but
if we're talking about bigger projects
and I'm getting to the DDD logic step by
step, one of the goals should be unified
set of rules somewhere. In this case,
for simple example, it's in form request
class. It's not DDD yet. Which leads me
to one step further. Form request is not
the best place to store that logic
because the request to create a post may
come not from the form and not from HTTP
like controller for create or update. It
may come from a cute job, automated
tests, artisan commands, some internal
service class and other parts of your
application. basically wherever and in
those places it's not easy to inject
form request class everywhere probably
possible in a hacky way but not ideal
form requests are usually for
controllers so then the question becomes
where do we put that logic and there are
various approaches but most of them lead
to some structure outside of typical
Laravel this is why bigger projects are
often Laravel kind of MVC layer but the
logic is inside of some service classes
or action classes or DTO's and all of
those are PHP classes not Laravel they
are just called from Laravel controllers
from routes and elsewhere but typically
you need to kind of stop thinking in
Laravel terms like how do I put
something in form request in eloquent
model or in controller and instead
define the structure somewhere in PHP
one of the ways is to define a service
class which is again PHP class there's
No artisan command php artisan make
service. There's a command php artisan
make class where you can put a service
in the name but that is php class. So in
that class you may do create an update
and inside that class you may have
validation. So then that service is
responsible for validation itself and if
validation fails it would throw PHP
exception. What happens with the
controllers then? So the controllers
could look something like this. You have
post service injected with constructor
property promotion and then you don't
work with eloquent or with form request.
You work with just service and then you
catch any exception that comes from that
service. If there's no exception then
you return the correct success result.
So then the controller becomes shorter
except for try catch. Maybe it may sound
longer but the logic is not in
controller and not in form request. It's
in kind of a black box which now can be
called from anywhere not necessarily
from a controller but that service could
be created the object of that service
created in a Q job in test again the
things that I mentioned. So now we moved
the logic even further from controller
to form request to service reusable
service and now all logic to create or
update the post is in one place reusable
and this is also one of the approaches
again there's no right or wrong here I'm
trying to explain just the theory why
the logic of the rules is moved from
controller to somewhere and now we'll
get to DDD but just kind of a side note
this is not the correct approach to
offload the logic. I'm just showing the
showcases and you may disagree with some
of those and you may probably not do
exactly like this in real life scenario
but this is just an example and with
that example kind of the wrong thing or
maybe not ideal thing is that service
class is responsible for eloquent model.
Couldn't eloquent model itself be
responsible for well itself? And this is
where we get to ddd to domain driven
design. And here you need to understand
basically all three words domain driven
and design. So let me explain in a
minute. Domain is too fancy word to be
honest. I don't like it because domain
is even ambiguous. It could mean a web
domain like.com. But domain you can call
it business logic or business rules. So
the application is driven. So domain
driven driven by business rules and
business logic first. which means that
the project is started being created
from business rules by business people
as well. So the goal is to define the
business rules behind the post later
eloquent model but it's just an object
it's called entity. So business people
should provide the specification or it
could be done with collaboration with
developers. What can happen with that
post entity? Can it be created? Can it
be updated? What are the validation
rules? What happens when the post is
actually published and stuff like that?
This should be in specification on paper
markdown, Google Doc, GitHub issue or
whatever documentation system and then
it is transformed into the code in PHP
language in this case with the idea that
anyone who would consume that logic
those rules it may be laravel it may be
symfony it may be whatever else the
logic is to design and this is where
third word comes in domain driven design
the logic and the idea and the goal is
to design that entity
to contain maximum amount of rules in
itself. So let me show you the example
from my course about university
management system and this is one of the
layers of that so-called bounded
context. It's almost the same as module
but here we have domain folder and here
we have entities and for example one of
the entities is student application and
again this is one of the interpretations
of DDD more like example so you would
understand the concept inside of that
student application class which is PHP
not eloquent model not migration nothing
from Laravel at all so this class
doesn't know anything about Laravel or
eloquent and this class is actually the
first thing that you create in DDD
project. So you don't start with Laravel
new, you don't start with routes and
controllers, you start with domain
logic. So that's why domain driven
design and this is what I would call the
specification the project requirement
just transformed into PHP language. So
you have all the properties with their
types with their validation required or
not with some specific so-called value
objects. If the rules are more
complicated than float or string, you
may have other entities. So for example,
you have student entity inside of
student application which then makes
student application kind of on higher
level so-called aggregate root. And then
when constructing that object, that
entity, this is where you put in the
validation most of it. So if something
is wrong at the time of creating that
object wherever that creating of the
object happens it may happen later in
Laravel or in some other layer of DDD
structure but this is kind of the final
validation logic the ultimate place
where all the business rules are written
here about the student application in
this case but in case of post model that
we saw earlier this would be the entity
of post and And also in that entity you
define what can happen with that entity.
In this case student application can be
submitted. And this is another thing
about DDD. One of the other goals with
domain driven design is the language and
the words and the naming of pretty much
everything. So for example class of
student application cannot be really
called application because it's
ambiguous. It should be student
application. One of the ideas is that
business guys like CEO or project
managers could technically look at the
code and still understand all the
concepts. Sometimes you may hear the
word ubiquitous language as one of the
goals of DDD which means that the logic
again the business logic the business
layer rules are defined first and
understandable by all parties all
developers all business layer guys and
this is kind of the bible of that
application whatever comes next in the
next layers of ddd lower there are
services repositories and then at some
point we get to eloquent models and
controllers much much later. And if you
haven't tried domain driven design and
you work with kind of a regular Laravel
developer and you think that this whole
structure is a big overkill, in most
cases it is. But again, we're talking
about bigger project. Imagine 50
entities, 10 to 20 developers and
different departments working on
different parts of the application. But
still all the business rules should be
manageable in kind of one place or in
one layer which is actually the domain
layer and the entities are kind of the
most sacred part of domain driven design
and that structure is of course not
typical to Laravel because domain driven
design is not about Laravel. It's not
about even PHP. It's a general
philosophy like object-oriented
programming or similar which you can
apply to basically any programming
language and also there are a lot of
interpretation as I mentioned about DDD
so that's why if you Google DDD
especially in Laravel there are various
folder structures because DDD is not
about folders specifically there are
various ways to skip some layers in the
structure or add some layer or maybe
name the layer differently sometimes and
here I want to quote one tweet, one
reply to my own tweet. When I was
working on that course on DDD, I
realized that you have to zoom out and
think way outside of Laravel to
understand DDD. I hope I explained it in
this video, but Joseph replied with very
profound thing. If in your project you
want domain driven design, you might not
really need Laravel or in other words
Laravel becomes smaller layer of your
whole application which comes as I said
in this video much later to consume the
structure of the business domain. And
here's another tweet I want to quote. If
you think that DDD is not for you, look
at the tweet by Mark. wasn't really a
fan of modules and DDD until someone
implemented it and then much later it
starts clicking, it starts working and
then everything is easier to know where
everything was. So this is one kind of
motivation to maybe consider DDD for
your next project if it's big right off
the gate to design the project again
domain driven design to design the
project structure in a way so it would
be manageable later in a year or in two
years by different teams with maybe even
different business management people
that domain driven design may help with
that for long term of the project and
the final thing kind of a motivation if
you think that DTD is not for you look
at says another tweet by Uladimir. The
logic is this. Since DDD is not about
Laravel or PHP, DDD may open the gate
for you to get other jobs from other
technologies not necessarily in Laravel
and also it may open the gate for you to
work at bigger companies at more serious
projects. Here are a few examples of
jobs mentioned by Uladimir here and
let's open a few of them randomly. So
senior PHP developer as you can see it's
not about Laravel and let's zoom in and
one of the responsibilities is maintain
highquality PHP applications and one of
the requirements is domain driven design
another example backend PHP Laravel
about the job see more this is in
Spanish language but the keyword DDD is
present and specifically hexagonal
architecture which is another separate
topic but basically this is part of a
job requirement. So yeah, if you don't
need DDD specifically on your projects
because they are smaller projects at the
moment, you may want to dive into it to
at least understand the logic and the
use cases to be able to work on bigger
projects more easily and not get lost in
the future. And for that I do recommend,
of course, I'm biased here, but my new
course about Laravel modules and DDD,
the second part of that course is about
DDD specifically. So one hour for
modules and one hour for DDD kind of
comparing the approaches. So over those
videos I explained the logic behind
other layers of that folder structure
that you saw in this video. Again it's a
simplified example. It's personal
interpretation of DDD but with the goal.
So you would understand the logic, the
goal and the way of thinking in domain
driven design terms which is not typical
to Laravel. I hope in this video I gave
you at least some motivation to at least
explore more serious structure like DDD.
But of course, as usual, we can discuss
in the comments below. My interpretation
may be just my interpretation and we can
talk about that in the comments below.
That's it for this time and see you guys
in other