go ddd

Go-ddd: modèle de conception piloté par le domaine à Golang

Bienvenue à go-ddd , un référentiel de référence / modèle de modèle démontrant l'approche de conception du domaine (DDD) dans Golang. Ce projet vise à aider les développeurs et les architectes à comprendre la structure DDD, en particulier dans le contexte de GO, et comment il peut conduire à des bases de code plus propres, plus maintenables et évolutives.

Aperçu

La conception axée sur le domaine est une méthodologie et un modèle de conception utilisé pour créer un logiciel d'entreprise complexe en connectant l'implémentation à un modèle en évolution. go-ddd le présente en créant un marché simple où Sellers peuvent vendre Products .

Pourquoi DDD?

• Langue omniprésente : promeut un langage commun entre les développeurs et les parties prenantes.
• Isolement de la logique du domaine : La logique du domaine est distincte des couches d'infrastructure et d'application, promouvant des principes solides.
• Évolutivité : permet des transitions d'architecture de microservices plus faciles.

Structure de référentiel

• domain : le cœur du logiciel, représentant la logique et les règles commerciales.
  • entities : objets fondamentaux de notre système, comme Product et Seller . Contient la logique de validation de base.
• application : contient des opérations spécifiques aux cases qui interagissent avec la couche de domaine.
• infrastructure : prend en charge les couches supérieures avec des capacités techniques comme l'accès à la base de données.
  • db : Accès et modèles de base de données.
  • repositories : implémentations concrètes de nos besoins de stockage.
• interface : la couche externe qui interagit avec le monde extérieur, comme les points de terminaison de l'API.
  • api/rest : Handlers ou contrôleurs pour gérer les demandes et réponses HTTP.

Autres principes

• Domaine
  • Ne doit pas dépendre d'autres couches.
  • Fournit une infrastructure avec des interfaces, mais ne doit pas accéder à l'infrastructure.
  • Implémente la logique commerciale et les règles.
  • Exécute des validations sur les entités. Les entités validées sont transmises à la couche d'infrastructure.
  • La couche de domaine définit les défauts des paramètres des entités (par exemple pour l'ID ou l'horodatage de création). Ne définissez pas les défauts de défaut dans la couche d'infrastructure ou même la base de données!
  • Ne pas divulguer des objets de domaine au monde extérieur.
• Application
  • Le code de colle entre le domaine et la couche d'infrastructure.
• Infrastructure
  • Les référentiels sont chargés de traduire une entité de domaine dans un modèle de base de données et de la récupérer. Aucune logique commerciale n'est exécutée ici.
  • Implémente les interfaces définies par la couche de domaine.
  • Implémente la logique de persistance comme l'accès à une base de données Postgres ou MySQL.
  • Lorsque vous écrivez au stockage, lisez des données écrites avant de les renvoyer. Cela garantit que les données sont écrites correctement.

Meilleures pratiques

• Ne retournez pas entités validées à partir de méthodes de lecture dans le référentiel. Au lieu de cela, renvoyez directement le type d'entité de domaine.
  • Les validations peuvent changer à l'avenir et vous ne voulez pas modifier toutes les données de votre base de données.
  • Sinon, vous ne pourrez pas lire les données de la base de données écrites avec une logique de validation différente.
• Ne mettez pas les valeurs par défaut (par exemple, horodatage actuel ou ID) dans la base de données. Définissez-les dans la couche de domaine (usine!) Pour plusieurs raisons:
  • C'est assez dangereux d'avoir deux sources de vérité.
  • Il est plus facile de tester la couche de domaine.
  • Les bases de données peuvent être remplacées et vous ne voulez pas avoir à modifier toutes vos valeurs par défaut.
• Lisez toujours l'entité après avoir écrit dans la couche d'infrastructure.
  • Cela garantit que les données sont écrites correctement et que nous ne fonctionnons jamais sur des données périmées.
• find vs get :
  • find des méthodes peut renvoyer null ou une liste vide.
  • Les méthodes get doivent renvoyer une valeur. Si la valeur n'est pas trouvée, lancez une erreur.
• Délétion: utilisez toujours la suppression douce. Créez une colonne deleted_at dans votre base de données et définissez-la sur l'horodatage actuel lors de la suppression d'une entité. De cette façon, vous pouvez toujours restaurer l'entité si nécessaire.

Commencer

1. Cloner ce référentiel:

git clone https://github.com/sklinkert/go-ddd.git
cd go-ddd
go mod download
go run ./...

Contributions

Les contributions, les problèmes et les demandes de fonctionnalités sont les bienvenus! N'hésitez pas à vérifier la page des problèmes.

Licence

Distribué sous la licence du MIT. Voir la licence pour plus d'informations.