DDD: comment les couches devraient être organisées?
je suis très nouveau dans le développement de logiciels. Personnellement, je pense que l'architecture stratifiée est un excellent moyen de réduire les complexités qui surgissent dans le processus de développement de logiciels dans l'approche orientée objet et, pour ne pas mentionner, de garder votre code organisé. Maintenant, j'ai rencontré quelques problèmes pour être introduit avec DDD (Domain Driven Design). Bien sûr, niveau débutant.
Ici, c'est –
Disons que, je veux construire une application pour sauver" personne " données liées dans base de données et afficher les détails d'une personne dans un datagrid wpf (DDD n'est certainement pas pour les applications d'une telle échelle, mais juste pour garder les choses simples pour un amateur comme moi). Donc, j'ai conçu une classe de domaine "personne", quelque chose comme –
public class Person
{
public Person(dataType paramA, dataType paramB)
{
_fieldA = paramA;
_fieldB = paramB;
}
private dataType _fieldA;
public dataType PropertyA
{
//encapsulates _fieldA
}
private dataType _fieldB;
public dataType PropertyB
{
//encapsulates _fieldB
}
public dataType PropertyX
{
//some code based on private fields
}
public dataType PropertyY
{
//some code based on private fields
}
private dataType MethodPQR(dataType param)
{
//some code
}
public dataType MethodUVW(dataType paramOne, dataType paramTwo)
{
//some code
}
}
Remarque:
je veux que la datagrade être lié à une certaine collecte observable, juste pour refléter n'importe quel type de changements instantanément.
c'est une application wpf mais pas nécessairement pour être dans le modèle MVVM et je veux délibérément utiliser le code derrière (je n'ai aucune idée si le code derrière lui représente la couche Application)
quel type de codes devrait appartenir à la couche Application?
- <!-- 2 - Devinez est, Je ne devrais certainement pas lier une complétion observable de mon objet de domaine (personne) comme itmsSource du datagrid. Quel type d'objet puis-je extraire de l'objet de domaine, et comment?
pour conserver un découplage entre les objets de la couche de présentation et les objets de la couche domaine peut y avoir une convention comme
“never instantiate domain objects directly in presentation layer”. Quelles sont alors les approches non"directes"?si le Code-derrière parle à la couche Application alors la couche Application devrait-elle parler au dépôt? Mais que faire si une sorte d'accès au domaine est nécessaire qui est accès aux données liées (peut-être pas dans cette application, mais il peut se produire, non? Qui est ce type X dans la couche domaine à qui la couche Application devrait parler?
je sais que toutes mes questions et mes problèmes sont d'un niveau très amateur. Mais ce sont des questions et des problèmes. Donc, si quelqu'un a le temps, toute réponse sera apprécier.
EDIT : Je ne suis pas sûr que le dépôt de données devrait avoir une référence de modèle de domaine.
1 réponses
en termes de DDD plus "classique", Oui les objets de domaine ne sont généralement pas autorisés en dehors du domaine. Mais ce n'est pas une règle absolue que les objets de domaine ne sont pas utilisés dans la couche de présentation. Par exemple Nu Objets représente une école de pensée où les objets du domaine sont utilisés directement. J'adhère moi-même principalement à une philosophie où les objets de domaine ne sont pas utilisés directement, donc je ne suis pas familier avec toutes les pratiques qu'ils suggèrent, je pense personnellement contraignant à un objet de domaine directement serait mal avisé, mais ... Il suffit de garder à l'esprit que tout le monde ne considère pas cela comme une exigence.
si vous n'autorisez pas les objets de domaine en dehors du domaine lui-même, vous utiliserez typiquement des objets DTO ou de transfert de données qui sont des propriétés simples seulement des classes qui n'ont pas de comportements de domaine. Les DTO reflètent souvent exactement la structure du modèle de domaine, mais ils n'y sont pas obligés.
la logique D'affaires est censée être mise en œuvre dans le modèle de domaine, tellement de ce qui l'is dans la couche application s'occupe de la coordination de divers services, généralement pour acheminer les données vers les applications du client et en provenance de celles-ci. Beaucoup de gens utilisent une certaine forme de SOA ou au moins des services web pour cela. Ceux-ci appellent les dépôts mais exigent aussi d'autres composants tels que les assembleurs pour prendre les objets de domaine retournés des appels de dépôt et et copier les valeurs de propriété dans les DTO, qui sont alors sérialisables et retournés à l'appelant. L'interlocuteur est souvent un présentateur ou un contrôleur mais si vous n'utilisez pas MVC ou MVP, l'appelant sera toujours dans la couche de présentation. Le voyage inverse est plus complexe - L'interface utilisateur peut renvoyer des Dto qui représentent des mises à jour ou des Dto qui représentent de nouveaux objets à ajouter. La médiation à l'aller et les activités sont principalement le but de la couche application.
en ce qui concerne l ' "accès non-data" de la couche domaine, il y a quelques exemples typiques. La plupart des gens se réfèrent habituellement au composant "X" que vous pensez peut-être comme un Domaine De Service. Un service de domaine diffère d'un service D'Application par sa proximité avec le modèle de domaine et la présence d'une logique commerciale réelle.
par exemple, si une application implique une sorte de placement de commande, il y a en fait deux préoccupations - placement de commande et exécution de commande. Les services d'applications médiatisent le transfert des données nécessaires pour formuler un placement de commande à L'IU, puis renvoient la commande que l'Utilisateur souhaite passer. Mais ce n'est qu' la médiation du transfert de données et c'est là que s'arrêtent les services D'Application. Un service de domaine peut alors être nécessaire pour appliquer des règles commerciales et construire des objets de domaine supplémentaires qui sont nécessaires pour remplir réellement cet ordre.
en général, je trouve que c'est un concept ou une métaphore utile qui peut être appliqué à de nombreux scénarios - un Service D'Application facilite une demande d'une sorte, en termes de demande présentation une seule . Un service de domaine d'autre part facilite la demande réelle réalisation.
le seul autre mode d ' "accès" autre que orienté données que j'ai rencontré ou que je peux facilement imaginer est la fonctionnalité orientée processus. Ce n'est pas le cas dans toutes les applications, mais c'est courant dans certains domaines. Par exemple, dans le domaine des soins de santé où je travaille, vous voudrez peut-être des applications qui intègrent des éléments importants de la gestion des données cliniques ainsi que du processus clinique. Je résous ce problème en ne faisant pas que accent sur le processus une partie de mon modèle de domaine et l'utilisation de différents outils pour cela à la place.
les techniques OOP ne sont pas bien adaptées à un processus lui-même, elles sont utiles pour fournir des données à un processus et pour saisir des données à partir d'un processus. Orienté objet est après tout aussi principalement orienté nom. Pour la gestion de processus en temps réel, vous avez besoin de" programmation axée sur les verbes "plus que"programmation axée sur les noms". Les outils de flux de travail sont des outils" axés sur les verbes " qui peuvent être complémentaires de domaine des modèles pilotés pour des applications à forte intensité de données et de processus. Je fais beaucoup de travail qui implique à la fois les modèles C# DDD et les Modèles de base de flux de travail, mais encore une fois, ce n'est nécessaire que pour certains types d'applications. De nombreuses applications d'affaires typiques ne nécessitent que des modèles de domaine et des services.
enfin, l'aspect le plus important du DDD n'est pas une technique ou une architecture. Le vrai cœur de celui-ci tourne autour du langage omniprésent et de l'interaction avec (dans mon opinion forte interaction DIRECTE avec) des experts du domaine de la distillation de la critique de la connaissance du domaine. (La plupart des entreprises qui prétendent faire DDD à mon avis ne le font pas parce que tant d'entreprises refusent de permettre à l'entreprise et le développement d'interagir directement, mais c'est un autre sujet... ) Ce sont les extractions et l'incorporation des connaissances du domaine, plutôt que n'importe quelle technique qui sépare en fait le DDD de l'OOP conventionnelle et c'est là que la valeur réelle du DDD prend naissance.
EDIT
en ce qui concerne l'utilisation du dépôt, le diagramme est correct. En général, la couche application passe toujours par un dépôt pour les objets du domaine. Tout d'abord, vous devez être en mesure d'apporter des données de l'application, et la plupart des applications aussi besoin d'un certain niveau de requête de capacité.
la couche de domaine OTOH fait habituellement interagir avec les référentiels. Généralement, vous voulez que le modèle de domaine soit autonome et découplé de tout technologie spécifique, I. e il doit s'agir d'une"connaissance pure du domaine". La persistance est intrinsèquement étroitement liée à une sorte de technologie spécifique, de sorte qu'en général les gens s'efforcent de rendre leurs modèles de domaine libres de toute mise en œuvre de la persistance. Vous avez des dépôts, mais en général vous ne voulez pas appeler les méthodes de dépôt dans le modèle de domaine.
dans le modèle de domaine lui-même, les objets sont obtenus sous forme de nouveaux objets (qui peuvent être instanciés directement ou par l'intermédiaire d'une) ou bien atteint en traversant des associations. Parfois, lors de la création d'un nouvel objet, il n'est pas pratique de passer tout ce qui est nécessaire dans un constructeur, donc c'est un cas où vous pourriez avoir besoin d'une sorte d'accès aux données dans le modèle de domaine lui-même. Habituellement, ce que les gens font, c'est passer dans un service de données via une interface de sorte que le modèle de domaine peut être fourni avec l'accès aux données, mais reste découplé de la mise en œuvre de la couche de données. Mais la plupart des objets de domaine agissent et interagissent avec d'autres objets de domaine qui sont déjà instanciés.