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

Bruno Tomé
May 24, 2018 · 4 min read

Laravel is a robust framework, I've been working with it for the last 2 years, and, until the begin of this year, its standard architecture was the sufficient for all the projects that I’ve worked with.

Then came 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 the choosen one was the Domain Driven Design.

About the DDD

The DDD induces the implementation of a continuous improvement scenario and can be an extremely useful tool to develop quality software that meets customer needs. This architectural pattern was created by Eric Evans. He has a book of patterns based on the author experience along of 20 years developing using Object Oriented techniques. The focus of this architectural pattern is the Domain, so to have software that fits perfectly with a specific domain, it is necessary to establish a Ubiquitous Language. In this language we have terms that are part of the daily conversations between business experts and development teams.

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)

There are 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 to your need. 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

One thing we keep in mind when we start applying the approach is that we do not want to "fight" with the framework, so all the modifications we’ve made are thinking of the ease of upgrading to the next versions, but trying to leverage the power of the framework within our domain.

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 app? 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 micro-service? So take the domain W into a micro-service (not so easy like saying, but more easy with DDD)

Conclusion

As I said before, there is no "right way" to do a DDD structure, after learning about this pattern we are now working with the structure shown in this article. But it is an ongoing process, you have to keep evolving to get the best productivity.

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:

Articles:

Repositories:

Bonus

What about the front end? DDD can be applied to the front end too. So see this bonus with a Vue.js project architecture with DDD.

Bruno Tomé

Written by

A passionate for web technologies entering the blockchain world. Degree in Computer Science at Federal Institute of Minas Gerais (IFMG).

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade