Der Artikel ist in der Tat fasst die Rede Greg „Ein Jahrzehnt der DDD, CQRS, Event-Sourcing“ bei DDD Europe 2016.
ich persönlich dem Titel dieser Zusammenfassung nicht mögen, da dies definitiv nicht der Punkt von Gregs Rede ist . Grundsätzlich, wie üblich, kommt es auf.
Wenn Greg über das System spricht, meint er die ganze Sache. Diese Thing, in DDD-Bedingungen, hat eine Kontext-Map, mit mehreren begrenzten Kontexten an Ort und Stelle. In der Regel können Sie auf dieser Kontextkarte Subdomänen identifizieren, wobei eine oder mehrere zusätzlich als Core-Domäne (n) identifiziert werden können.
Wenn Sie Ihre Kerndomäne haben - es wird sich gut für fortgeschrittene Techniken eignen, wären dies traditionelle DDD-Taktiken wie Aggregate oder "schickere" Sachen wie Event-Sourcing. Die Implementierung muss in der Tat auf den Kontextanforderungen basieren.
Von dem, was Sie beschreiben, haben Sie eine gute Passform für Event-Sourcing. Aber Sie könnten über andere Teile Ihres Systems nachdenken, z. B. Kunden-/Kontaktverwaltung und Mitarbeiterverwaltung. Diese Details sollten von irgendwo kommen. Sind das vielleicht CRUD-Kandidaten? Also, wenn Ihre Kerndomäne in diesem Fall ist, Interaktionen zwischen Mitarbeitern und Kunden zu verfolgen, irgendeine Art von CRM, können Sie entscheiden, das Teil mit Event-Sourcing und anderen Teilen Ihres Systems mit weniger fortgeschrittenen Techniken zu bauen.
Denken Sie daran, alle Teile auf die Kontext-Maps trotzdem, einschließlich externer Systeme, dann sehen Sie, dass das System Wort bedeutet in dem Artikel und der Diskussion.
Ich denke, dass es darauf ankommt, was "System" bedeutet. Wenn Sie sich auf die gesamte Organisationssoftware als System beziehen, handelt es sich wahrscheinlich um ein Anti-Pattern. –