Was sind die typischen Schichten in einer Zwiebelarchitektur?

Question

Ich studiere derzeit das domänenbasierte Design und versuche es für ein WPF-Projekt anzuwenden. Ich sah ein paar Tutorial-Videos, und lesen viele Artikel, wie:

• Onion archicecture dependencies in the same layer: Infrastructure and Web communicating
• http://eohmicrosoft.blogspot.fr/2012/08/laying-it-out-onion-architecture.html
• Domain Driven Design: Domain Service, Application Service

ich den Fokus verstanden auf Schnittstellen und Inversion der Kontrolle. Ich habe gelesen, dass es einige wiederkehrende Layernamen gab (Domäne/Kern für die Darstellung der Wissenssphäre, Infrastrukturen für Persistenz, Anwendung für ... ich verstehe nicht), aber sie ändern sich, abhängig von den Artikeln, die ich gelesen habe. Einige erscheinen sogar nicht.

Wäre es möglich, eine Liste aller Schichten zu haben, die theoretisch in einer Zwiebelarchitektur benötigt werden, um alle Bedürfnisse und Probleme zu erfüllen, mit ihrer Absicht (welche Art von Code enthalten sie, welche Art von Bedarf) sie versuchen zu erfüllen, auf welche Ebene müssen sie verweisen), bitte?

Answer 1

Stimmen Sie völlig mit Hippooms Antwort überein. Es ist perfekt, von dort aus zu starten.

Nun

Ich las es einige wiederkehrende Ebenennamen (Domain/Kern für die Darstellung der Sphäre des Wissens, Infrastrukturen für persistance, Anwendung für ... Ich verstehe nicht) waren , aber sie ändern sich, abhängig von Artikeln, die ich las. Einige erscheinen sogar nicht.

Ja, die Entscheidung über Layer in einer Anwendung hängt von vielen Faktoren in einem bestimmten Szenario ab. Es ist so, als ob Universitäten ihre Programme aufteilen und Lehrpläne erstellen. Es hängt von der Kapazität/Vielfalt ab, die sie bedienen wollen, von der Notwendigkeit und dem Zweck der Universität. Es ist sehr unterschiedlich in Details (Benennung und Partitionen) auf der ganzen Welt, aber der Kern und die Absicht ist immer gleich.

Auf dieselbe Weise hängt die Verwendung von Layern in einer Anwendung vom Bedarf und Umfang ab. Irgendwann haben die Architekten den Namen der Schichten gemäß ihrer Philosophie und Konvention in der Organisation definiert. So können sich die Absicht und der Name manchmal unterscheiden. Aber die Code Idee, verkaufsfähig, wartbar und erfüllt die functional and non-functional requirements in der Hand, bleibt immer gleich.

Wäre es möglich, eine Liste aller Schichten zu haben, die in der Theorie, in einer Zwiebel Architektur erforderlich sind alle Anforderungen und Problemen konfrontiert, mit ihrer Absicht (welche Art von Code enthalten sie, was Art von müssen sie versuchen zu erfüllen, welche Schicht müssen sie verweisen), bitte?

Hippoom hat es schon sehr gut gemacht und er beschrieb auch die Absicht in Schuss.
Standardschichten sind hier beschrieben: http://jeffreypalermo.com/blog/the-onion-architecture-part-1/
Wie bereits erwähnt, können Schichten je nach Anwendung variieren.

Ich hoffe, es würde Ihnen helfen. Vielen Dank.

Enthalten Details wie pro Davids ersten Kommentar unten:

Anwendungsdienste implementieren die Anwendungsfälle und machen Anrufe an die Domain Services und Domain-Entitäten und Infrastructure Services getan, um den Job zu bekommen. Es bietet Schnittstellen zur Außenwelt (hauptsächlich UI-Layer-Projekte), um bestimmte Funktionalitäten zu erreichen. UserService ist beispielsweise ein Anwendungsdienst. UserService kann Funktionen zur Überprüfung auf Authentifizierung für Benutzer und Autorisierung für bestimmte Ressourcen, Änderungsprivilegien für einen Benutzer durch Admin, Sperrung des Benutzers usw. bereitstellen. Um diese Anwendungsfälle zu erreichen, würde er UserRepository und UserEntity aus unteren Schichten verwenden.

Domain-Dienste sind applikationsunabhängig; Sie bieten die Möglichkeit, die Integrität des Domänenmodells sicherzustellen, indem CRUD-Operationen (Create, Read, Update, Delete) und der Datenzugriff gekapselt werden. Sie haben normalerweise Repositories von Domain-Objekten und UoW Implementierung usw. in Zwiebel-Architektur.

Answer 2

Nur einige persönliche Erfahrung, ich benutze diese in Eric erwähnt Architektur ist auch DDD Buch:

Kurz:

1) Schnittstellen ist Komponenten bestehen, die mit Benutzer verantwortlich sind (einen echten Endpunkt für die Interaktion Benutzer oder eine Remote-Maschine), Web-MVC-Controller, Web-View-Objekt, Remote-Fassade zum Beispiel.

2) Anwendung definiert, welche Funktionen Ihr System bietet. Ich denke, es ist stark mit der Ebene Interfaces gekoppelt. Wenn Sie eine Methode in Application definieren, müssen Sie häufig auch eine Interfaces-Klasse/Methode hinzufügen. Mehrere Interfaces-Klassen/Methoden können jedoch vom selben Application-Objekt abhängig sein. Sie stellen beispielsweise sowohl eine Web-UI als auch einen Web-Service zur Verfügung.

3) Domain, der stabilste Teil Ihres Systems. Im Sprachkontext zum Beispiel sind Wort/Satz Domänenobjekte, die ihre eigene Bedeutung haben, die ich zu dieser Antwort formulierte. Sie könnten mich also als ein Anwendungsobjekt betrachten, obwohl nicht gut, weil ich kein fließendes Englisch spreche: P

4) Infrstructure, eigentlich glaube ich nicht, dass dies eine Schicht ist, es implementiert alle oben genannten drei . Zum Beispiel haben Sie eine Schnittstelle OrderRepository in Ihrer Domain-Schicht und Sie könnten es mit einem orm-Framework (Persistenz-Infrastruktur) implementieren. Die meisten Infrastrukturobjekte sind Adapter (implementiert eine Schnittstelle in der Ebene Application/Domain/Interfaces und passt sich an externe Komponenten wie Datenbank, Messaging-Provider, Mail-Server usw. an).

Hoffe, das hilft.

Update für Infrastruktur Vorsatz:

Dies ist eines unserer Projekt Paket Ansicht.

Es gibt einige Adapter in der Infrastrukturschicht:

1.infrastructure.channel.XXX jedes Paket mehrere Adapter zu einem bestimmten Online-Payment-Anbieter enthält.

2.infrastructure.payment enthält Adapter zu einem Zahlungssystem unserer Organisation, aber es ist in einem anderen beschränkten Kontext. Wir verwenden MakePaymentService (ein Domain-Service), um das Zahlungssystem von anderen Teilen dieses Systems zu entkoppeln.

3.infrastructure.messaging enthält Adapter-Messaging-Provider bieten wir eine jms für PaymentWasMadeNotifier (Application Service)

4.infrastructure.persistence enthält Adapter zur Datenbank implementieren, bieten wir ein iBATIS (ein ORM-Framework in Java) für Domain Repositories.

Diese obigen Adapter implementieren alle einige Schnittstellen in den Anwendungs ​​/ Domänen-Schichten. Im Folgenden finden Sie einige "Service", aber sie sind generic:

5.infrastructure.mail

6.infrastructure.logging

7.infrastructure.security

Diese Paket über eine Schnittstelle aussetzen und Implementierungen. Zum Beispiel stellen wir eine MailManager-Schnittstelle zur Verfügung, die bestimmten Funktionen nicht entspricht. Der Betreff, der Inhalt hängt von der Anwendungsschicht/Domänenebene ab. Wir bieten eine Implementierung mit Javamail im selben Paket.

public interface MailManager { 
void send(String subject, String content); 
} 

8.infrastructure.time dies ein besonderes ist, haben wir einige cron-Job in diesem System, so stellen wir eine Uhr die Zeit von der Arbeit zu entkoppeln vorstellen Einstellung und damit seine freundliche Tests (Just, dass wir ein Job, sollte es am 25. jeden Monat gestartet werden, können wir den Job testen, indem wir die aktuelle Zeit auf den 25. stellen, selbst wenn es heute 1. ist). Wir bieten eine Implementierung in Persistenz-Paket (Aus irgendwelchen Gründen müssen wir verwenden Datenbank‘Zeit in der Produktion)

public interface Clock {  
    Date now(); 
} 

Also mein Verständnis ist: Infrastruktur-Service/Implementierungen auf Ihre anderen drei Schichten bietet, aber sie sind technologiespezifische . Beispiel: Betreff, Inhalt, Von, Bis, CC sind Domänenmodelle im Mailkontext, aber sie sind Infrastrukturen in Ihrem Domänenkontext. Die Infrastrukturebene trennt sie für Sie.