Modélisation d'un agrégat avec éloquent

Le modèle agrégé est une pierre angulaire de la conception axée sur le domaine (DDD), cruciale pour maintenir la cohérence des données et appliquer les règles métier dans les collections d'objets. Cet article explore les complexités de la mise en œuvre d'agrégats à l'aide de l'éloquente de Laravel, un modèle d'enregistrement actif.

Les meilleures pratiques architecturales préconisent la séparation du modèle de domaine des problèmes d'infrastructure. Cependant, un enregistrement actif, de par sa nature (emballage de lignes de base de données), couple étroitement le modèle de persistance, conduisant potentiellement à des conceptions complexes et erronées.

Prise des clés:

• Les agrégats sont centraux du DDD, garantissant la cohérence en regroupant des objets en une seule unité, régis par une racine agrégée. L'interaction externe est uniquement à travers cette racine.
• Le couplage inhérent à l'enregistrement actif à la persistance rend le découplage difficile, augmentant la complexité lorsqu'il est utilisé avec des agrégats.
• La mise en œuvre d'agrégats avec un enregistrement actif est réalisable mais difficile. Le traitement des objets d'enregistrement actifs comme les objets traditionnels peut conduire à un code désordonné.
• L'enregistrement actif excelle dans le développement rapide des applications (RAD), mais ses compromis le rendent moins adapté à la modélisation des agrégats complexes.

Comprendre les agrégats:

Un agrégat est un groupe d'objets agissant comme une seule unité, avec un objet désigné comme racine agrégée. Toutes les interactions externes doivent passer par la racine, qui gère la cohérence des objets dans sa frontière. Les limites agrégées définissent les lunettes de transaction; Un seul agrégat peut être engagé par transaction. Les modifications aux autres agrégats nécessitent une cohérence éventuelle.

Vaughn Vernon "Implémentation de la conception axée sur le domaine" décrit les principaux principes de conception agrégés:

1. Protéger les invariants dans les limites de cohérence.
2. Concevoir de petits agrégats.
3. Référencer les autres agrégats par identité uniquement.
4. Utiliser une cohérence éventuelle en dehors de la frontière.

Un exemple de blog:

Modérons un article de blog. Post est une racine agrégée appropriée, avec Title et Copy comme objets de valeur. Author reste en dehors de la frontière, référencée par ID. Comment est une entité au sein de l'agrégat Post. Les agrégats trop importants ont un impact sur les performances; Gardez-les petit et bien défini.

une classe Post simplifiée (sans éloquent):

final class Post {
    // ... properties and methods ...
    public function comment(Message $message) {
        if ($this->locked->isLocked()) {
            throw new PostIsLocked;
        }
        // ... add comment ...
    }
}

Intégration éloquente:

Maintenant, incorporons éloquents:

final class Post extends Eloquent {
    // ... methods ...
    public function comments() {
        return $this->hasMany(Comment::class);
    }
    // ... accessors and mutators for Value Objects ...
}

Eloquent simplifie le code en gérant les propriétés en interne. Cependant, cela passe à l'orientation du comportement aux données, ce qui conduit potentiellement à des modèles de domaine anémique. La méthode comments() facilite les relations d'Elogent.

relever les défis:

• Données par rapport au comportement: L'accès direct des données d'Eloquent peut inciter les développeurs à contourner le comportement de la racine globale, compromettant l'application des règles commerciales. Utilisez toujours le Tell, ne demandez pas le principe.
• Objets de valeur: Les accessoires et mutateurs d'Eloquent aident à gérer les objets de valeur, en maintenant l'intégrité des données.
• invariants: Le constructeur d'Eloquent empêche l'application invariante à la création d'objets. Utilisez des méthodes d'usine ou des constructeurs nommés dans la racine agrégée ou une classe connexe pour l'atténuer. Cependant, cela se heurte aux méthodes statiques existantes d'Eloquent.
• Relations: L'accès directement à des relations contourne la racine globale, sapant l'application des règles commerciales. Encapsuler la gestion des relations dans la racine agrégée.

Conclusion:

Bien que possible, la modélisation d'agrégats avec éloquente présente des défis importants. L'accent mis par le modèle d'enregistrement actif sur les données entre en conflit avec la nature orientée objet des agrégats. Le choix dépend des besoins et des priorités du projet. La vitesse des enregistrements actifs est bénéfique pour RAD, mais pour les domaines complexes, les compromis pourraient l'emporter sur les avantages. Une attention particulière et une approche disciplinée sont essentielles lors de la combinaison des principes DDD avec des orms enregistrés actifs.

FAQS (Adressant les FAQ fournies):

Les FAQ fournies sont adéquatement abordées dans la réponse révisée ci-dessus. Les explications des agrégats, des objets de valeur, des mutateurs et les défis de les utiliser avec éloquent sont intégrés dans le texte principal pour un meilleur flux et une meilleure clarté.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!