A Domain Driven Design (DDD) approach to the Laravel Framework

Laravel is a robust framework. I've been working with since 2016 and until the beginning of 2018 it's standard structure was sufficient for all the projects that I’ve worked with.

So I had a new challenge, we were not sure how big the new project would be, but we already knew that the project should be ready to scale at most as possible when necessary, accepting the entry of new developers on the team without difficulty, perhaps turning each module of the application into a microservice in the future. So I started to learn about software architectural patterns and Domain Driven Design (DDD) approach.

About the DDD

To maintain focus on the domain, we need to isolate the domain model from the other parts of the system. One way to do this is to use a layer architecture:

  • UI (User Interface): The responsible of displaying information to the user, and accept new data. It could be implemented for web, console, or any presentation technology, present or future;
  • Application: This layer has no business logic. It is only a thin layer, responsible for connecting the User Interface to the lower layers;
  • Domain: Represents the concepts, rules and business logic. The whole DDD focus is on this layer. Communication with other systems, persistence details, are forwarded to the infrastructure layer;
  • Infrastructure: The structural resources that support the upper layers. They are usually the parts of a system responsables of persistence of data, connections to databases, sending messages over networks.

A domain, also known as context or subject, is not necessarily an entity.

Understand domains as an application knowledge domain. In a blog application, we would have Blog with a domain, inside it we would have the business rules to interact with posts, like repositories, models, services … Post, Comment and Category are examples of models that would be inside Blog.

One tip for identifying a domain is when there is more than one entity interacting with it.

(Vinícius Reis)

Two things you should know before to see our DDD approach:

  1. The laravel/laravel is yours, it comes with a standard skeleton but you can modify it's default structure for the best approach for your needs. Do not confuse with the laravel/framework in your vendor.
  2. There is no "right way" to make a DDD structure, it is a continuous process of improvements that you will learn and adapt over time.

Our DDD approach

At the time I wrote this article, our laravel structure looks like this:

A Domain Driven Design (DDD) approach to the Laravel Framework

Now, do you think it's easier to keep this structure for a huge application? I think, because:

  • If there is a bug on the X domain, go solve it on the X domain
  • There is a new feature do be implemented about Y? go to the Y domain
  • A new developer is in charge of domain Z? so go develop inside Z domain
  • The domain W could be uncoupled into a microservice? So take the domain W into a microservice (not so easy like saying, but you get it).


If you read this far and wondered “where can I learn more about Domain Driven Design?” I will put below some of the articles and repositories I have read in recent weeks on the subject:




A developer who loves to create his own online business. Persistence 🚀

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store