J'essaie de garder les choses très simples à chaque fois que je peux, si quelque chose comme cela fonctionne pour moi:
Myapp.Domain - Tous les domaines cours spécifiques partagent cet espace de noms
Myapp.Data - couche mince extrait la base de données du domaine.
Myapp.Application - Tous "code de soutien", l'exploitation forestière, le code partagé des services publics, les consommateurs de services, etc.
Myapp.Web - L'interface utilisateur Web
Ainsi, les classes seront par exemple:
- Myapp.Domain.Sales.Order
- Myapp.Domain.Sales.Customer
- Myapp.Domain.Pricelist
- Myapp.Data.OrderManager
- Myapp.Data.CustomerManager
- Myapp.Application.Utils
- Myapp.Application.CacheTools
Etc
L'idée que j'essaie de garder à l'esprit que je vais est le long que l'espace de noms « domaine » est ce qui illustre la logique réelle de l'application. Donc ce qui se passe là est ce que vous pouvez parler aux "experts du domaine" (les mecs qui utiliseront l'application). Si je suis codage quelque chose à cause de quelque chose qu'ils ont dit, il devrait être dans l'espace de noms de domaine, et chaque fois que je code quelque chose qu'ils ne sont pas mentionnés (comme l'exploitation forestière, le suivi des erreurs, etc.), il ne devrait pas être dans l'espace de noms de domaine. Pour cette raison, je me méfie également de la création de hiérarchies d'objets trop complexes. Idéalement, un dessin quelque peu simplifié du modèle de domaine devrait être intuitivement compréhensible par les non-codeurs.
A cette fin, je ne commence pas normalement en pensant à des modèles dans plus de détails. J'essaie de modéliser le domaine aussi simple que je peux le faire, en suivant juste les directives de conception orientées objet standards. Qu'est-ce qui doit être un objet? Comment sont-ils liés? DDD dans mon esprit est sur la manipulation de logiciels complexes, mais si votre logiciel n'est pas très complexe au départ, vous pourriez facilement finir dans une situation où la façon de faire DDD ajoute de la complexité plutôt que de le supprimer.
Une fois que vous avez un certain niveau de complexité dans votre modèle, vous allez commencer à voir comment certaines choses doivent être organisées, et vous saurez quels sont les modèles à utiliser, quelles sont les classes d'agrégats, etc.
Dans mon exemple , Myapp.Domain.Sales.Order serait une racine globale dans le sens que lorsqu'il est instancié, il contiendra probablement d'autres objets, comme un objet client et collection de lignes de commande, et vous n'accéder aux lignes de commande pour ce particulier commander à travers l'objet de la commande. Cependant, pour simplifier les choses, je n'aurais pas d'objet "maître" qui ne contienne que le reste et qui n'a pas d'autre but, donc la classe de commande aura elle-même des valeurs et des propriétés utiles dans l'application.
Je vais donc faire référence à des choses comme:
Myapp.Domain.Sales.Order.TotalCost
Myapp.Domain.Sales.Order.OrderDate
Myapp.Domain.Sales.Order.Customer .PreferredInvoiceMethod
Myapp.Domain.Sales.Order.Customer.Address.Zip
etc.
... est logique Ordre et client êtes-vous AggRoots droit? Donc quand vous référencez votre objet Order, vous devez le faire comme: Myapp.Domain.Sales.Order.Order ?? –
Oui et non - J'ai un peu prolongé mon exemple, car la section des commentaires est un peu trop courte. – Console
Les classes 'Manager' dans l'espace de noms' Data' me font chose du modèle anémique –