Kommunikation zwischen Ebenen in DDD

Beim Lesen der DDD-Literatur habe ich mir folgende Ebenen ausgedacht:

• Application Outsider World (Controller, Crons usw.)
• Application Services(oder UseCases) - Orchestriert mehrere Domänendienste oder Infrastrukturdienste. Sie werden von angerufen Outside World. Sie wissen, was zu tun ist
• Domain Services - die enthält, wie die Dinge gemacht werden (basierend auf Repository-Schnittstellen)

Frage : Gibt es Best Practices für die Kommunikation zwischen Ebenen?

Was ich weiß: - Application servicessollte "gesuchte Daten" zurückgeben, die offengelegt werden sollen, und einen Teil des "Erfolgs" der Transaktion (Warnungen, Fehler, Infos) - Die Daten, aus denen eine Application ServiceRückgabe stammt, sollten gesammelt Domain Servicesund / oder Infrastructure Serviceszusammengestellt werden.

Controller <-> Application Service <-> Domain Service          
                                   <-> Infrastructure Service

Dies sind einige meiner zweideutigen Gedanken:

• Sollten alle Methoden Application Serviceein bestimmtes DTO haben, das die "Anfrage" als Parameter enthält? Wie AddItemToCardCommandDto(das hat alle benötigten Daten gekapselt). Wie wäre es mit einem Generikum ResultObject, das nur ein paar Methoden wie getResultund hasErrorrsoder hat getMessages?

• Wie sollen DomainServiceDaten und Fehler zurückgegeben werden? Sollten sie ausnahmsweise Fehler zurückgeben? Das scheint seltsam, weil für mich die Bussines Validation aufgerufen werden sollte, DomainServicesda sie Teil der Geschäftsregeln sind.

Ich würde sagen, dass DTOs das Design des Modells verwässern würden. Wir können damit umgehen, dass wir keine DTOs verwenden müssen, indem wir unser Modell umgestalten und unsere APIs so entwerfen, dass sie die umgestalteten Modellobjekte verwenden.

Die Antwort auf Frage 1: Der Anwendungsdienst kann Methoden mit einer Signatur haben

void addItemToCard(Item item, Card card);

Die Methoden können einen Rückgabetyp haben oder nicht, abhängig von der Art der Operation, die wir ausführen möchten, und den Daten, die wir über Ebenen hinweg übertragen möchten. Sie müssen sicherstellen, dass jede Ebene eine bestimmte Schnittstelle hat und verschiedene Ebenen über diese Schnittstelle für alle Komponenten in der Anwendung miteinander sprechen.

Z.B:

List<Items> getItemsOnCard(String cardID);
//returns list of items or empty list if no item can be found.

List<Offers> getOffersApplicableOnCardForItem()
//should return list of Offers or empty list if no item can be found. Should not return a null if no items can be found

Es ist wichtiger sicherzustellen, dass alle Methoden dasselbe Verhalten aufweisen, um die Schnittstelle intakt zu halten.

Antwort auf Frage 2:

Ich denke, DDD empfiehlt 3 Schichten, wenn ich mich richtig erinnere. Domain Intelligence in der Anwendungsschicht hilft und bedeutet, dass Ihre Anwendung an die Domain gebunden ist und einen begrenzten Kontext hat. Sie können zusätzliche Ebenen hinzufügen, wenn Sie der Meinung sind, dass 3 nicht ausreicht. Ausnahmen können verwendet werden, um Informationen über Ebenen hinweg zu kaskadieren. Daten können in Platzhaltern von benutzerdefinierten Ausnahmen für Unternehmen enthalten sein.

Ich hoffe, dies beantwortet einige der Fragen, die Sie haben.