Building Domain-Driven Design in Laravel

The Problem with Domain-Driven Design in Laravel

If you've worked on a large-scale Laravel application, you've likely encountered the issue of a bloated codebase with complex business logic scattered throughout your controllers and models. This can lead to maintainability nightmares, making it difficult to understand the flow of your application and debug issues. Domain-Driven Design (DDD) offers a solution to this problem by providing a framework for modeling complex business domains in a structured and maintainable way.

Introduction to Domain-Driven Design Architecture

Domain-Driven Design is an approach to software development that focuses on understanding the core business domain and modeling it in code. The DDD architecture consists of several key components: entities, value objects, aggregates, repositories, and domain events. Entities represent objects with identity, value objects are immutable and have no identity, aggregates are clusters of related entities, repositories encapsulate data access, and domain events represent something that has happened in the domain.

In a DDD architecture, the domain layer is the core of the application, and it's where the business logic resides. The infrastructure layer provides the necessary supporting components, such as databases and file systems, while the application layer coordinates the interaction between the domain and infrastructure layers.

The Implementation

Let's take a look at how we can implement a simple DDD architecture in Laravel. We'll start with a User entity, which will be our aggregate root.

use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;

class User extends Authenticatable
{
    use Notifiable;

    protected $fillable = [
        'name',
        'email',
        'password',
    ];

    public function getAvatarAttribute()
    {
        return 'https://example.com/avatar/' . $this->id;
    }
}

Next, we'll create a UserRepository that will encapsulate data access for our User entity.

use App\Models\User;

class UserRepository
{
    public function find($id)
    {
        return User::find($id);
    }

    public function save(User $user)
    {
        $user->save();
    }
}

We'll also define a UserCreated domain event that will be triggered when a new user is created.

use App\Models\User;

class UserCreated
{
    public $user;

    public function __construct(User $user)
    {
        $this->user = $user;
    }
}

Finally, we'll create a UserService that will coordinate the interaction between the domain and infrastructure layers.

use App\Models\User;
use App\Repositories\UserRepository;
use App\Events\UserCreated;

class UserService
{
    private $repository;

    public function __construct(UserRepository $repository)
    {
        $this->repository = $repository;
    }

    public function createUser($name, $email, $password)
    {
        $user = new User();
        $user->name = $name;
        $user->email = $email;
        $user->password = bcrypt($password);
        $this->repository->save($user);
        event(new UserCreated($user));
    }
}

Value Objects and Tactical Design

Value objects are immutable objects that have no identity and are used to describe the state of an entity. In our example, we could use a Money value object to represent the user's balance.

class Money
{
    private $amount;
    private $currency;

    public function __construct($amount, $currency)
    {
        $this->amount = $amount;
        $this->currency = $currency;
    }

    public function getAmount()
    {
        return $this->amount;
    }

    public function getCurrency()
    {
        return $this->currency;
    }
}

Tactical design refers to the process of designing the internal structure of the domain model. This includes the use of entities, value objects, aggregates, and domain events to model the business domain.

Common Pitfalls

• Not separating the domain logic from the infrastructure logic, leading to a tight coupling between the two.
• Not using value objects to describe the state of an entity, leading to primitive obsession.
• Not using aggregates to define the boundaries of a transaction, leading to inconsistent data.

Key Takeaways

• Use Domain-Driven Design to model complex business domains in a structured and maintainable way.
• Separate the domain logic from the infrastructure logic to avoid tight coupling.
• Use value objects to describe the state of an entity and avoid primitive obsession.
• Use aggregates to define the boundaries of a transaction and ensure data consistency.
• Use domain events to notify other parts of the application of changes to the domain.