Domain

Après avoir présenté la vision globale de la Clean Architecture, nous entrons maintenant dans son cœur battant ❤️ : la couche Domain.

C’est la couche la plus importante et la plus stable de toute l’architecture. Elle contient ce qui donne réellement de la valeur à l’application : la logique métier pure.

👉 Tout le reste (UI, base de données, frameworks) existe pour servir le Domain, jamais l’inverse.

---

3.1. Qu’est-ce que la couche Domain ?

Le Domain représente le métier, rien de plus, rien de moins.

Il répond à des questions fondamentales :

• Quels sont les concepts clés du métier ?
• Quelles règles doivent toujours être respectées ?
• Comment ces concepts interagissent entre eux ?

La couche Domain est totalement indépendante :

• ❌ pas d’UI
• ❌ pas de base de données
• ❌ pas de framework
• ❌ pas de réseau

👉 Elle doit pouvoir être comprise, testée et exécutée en isolation complète.

---

3.2. Les composants principaux du Domain

La couche Domain s’articule généralement autour de trois types de composants.

---

3.2.1. Les Entités (Entities)

Les entités représentent des objets métier ayant une identité propre et une durée de vie.

Exemples classiques :

• User avec un identifiant unique et des règles liées à son état
• Invoice avec des règles de calcul de taxes
• Order avec des contraintes sur ses statuts

👉 Une entité doit toujours être dans un état valide.

---

3.2.2. Les Objets de Valeur (Value Objects)

Les objets de valeur représentent des concepts métier sans identité propre. Ils sont définis uniquement par leurs attributs.

Exemples :

• EmailAddress
• Money
• Address

👉 Ils permettent d’éviter les types primitifs trop pauvres (string, decimal, etc.).

---

3.2.3. Les Services de Domaine (Domain Services)

Certaines règles métier ne trouvent pas naturellement leur place dans une seule entité.

Dans ce cas, on utilise un service de domaine.

Exemples :

• calculer le total d’une commande avec plusieurs règles
• appliquer des politiques de remise complexes

⚠️ Un service de domaine ne doit jamais devenir un fourre-tout.

---

3.3. Ce que le Domain ne doit jamais contenir

Pour rester pur et stable, le Domain doit être strictement protégé.

Il ne doit contenir aucune trace de :

• Base de données
• ORM
• API externes
• UI
• Frameworks

👉 Si un détail technique apparaît dans le Domain, c’est souvent un signal d’alerte 🚨.

---

3.4. Exemple simple en C#

Voici un exemple volontairement simple illustrant les principaux concepts.

// Value Object
public class EmailAddress
{
    public string Value { get; }

    public EmailAddress(string value)
    {
        if (!value.Contains("@"))
            throw new ArgumentException("Email invalide", nameof(value));

        Value = value;
    }
}

// Entity
public class User
{
    public Guid Id { get; }
    public EmailAddress Email { get; }

    public User(Guid id, EmailAddress email)
    {
        Id = id;
        Email = email;
    }
}

// Entity
public class Order
{
    public IReadOnlyList<OrderItem> Items { get; }
    public bool HasDiscount { get; }

    public Order(IReadOnlyList<OrderItem> items, bool hasDiscount)
    {
        Items = items;
        HasDiscount = hasDiscount;
    }
}

public class OrderItem
{
    public decimal Price { get; }

    public OrderItem(decimal price)
    {
        Price = price;
    }
}

// Domain Service
public class OrderService
{
    public decimal CalculateTotal(Order order)
    {
        var total = order.Items.Sum(item => item.Price);

        if (order.HasDiscount)
            total *= 0.9m;

        return total;
    }
}

Dans cet exemple :

• la logique métier est centralisée
• aucune dépendance technique n’est introduite
• tout est facilement testable

---

3.5. Pourquoi le Domain est au centre ❤️

• 🪨 Stabilité : il change moins souvent que l’UI ou l’infrastructure
• 🔁 Réutilisabilité : il peut servir plusieurs interfaces
• 🛡️ Protection : il est isolé des choix techniques

En Clean Architecture, protéger le Domain, c’est protéger l’application.