Domain-Modellierung, Domain-Objekte in DDD

Question

Ich bin wirklich neu in DDD und versuchen, einige der Konzepte zu erfassen.

Könnte mir jemand die Idee hinter Domänenmodellierung in DDD erklären.

Ich habe bereits durch Wikipedia-Erklärung gegangen: http://en.wikipedia.org/wiki/Domain_model, aber scheint immer noch, als gäbe es einige Grauzonen in meinem Verständnis.

Nach dem, was ich verstanden, beinhaltet Domänenmodellierung ein Modell um die Geschäftseinheiten bauen ihre Beziehungen zum Ausdruck bringen, drücken die Unternehmen, die usw. in dem Modell teilnehmen ..

Ist das nicht etwas, das in der Praxis gewesen immer? In der objektorientierten Welt modellieren Sie Geschäftsentitäten in Klassen, Objekte usw. und bauen die Software um diese herum.

Was ich nicht verstehe, ist der Schwerpunkt Domain Modeling wird in DDD. Ist es die gleiche Objekt/Klassen-Modellierung, die Sie in der OO-Welt finden, oder ist das etwas Neues für DDD? Wie unterscheidet es sich von objektorientiertem Design/Modellierung?

Ihre Antworten werden sehr geschätzt.

Answer 1

Eine Unterscheidung ist, dass eine "richtige" Implementierung der Domain Model Pattern in DDD von übergreifenden Bedenken isoliert ist.

Zum Beispiel enthält es nichts mit Datenbanken oder anderen Persistenz zu tun. Wo es Validierungslogik enthält, ist es Geschäftsvalidierung, nicht "überschreitet der Name die Spaltenlänge?" Validierung.

Die Idee ist, dass das Domänenmodell "das Geschäft" - in geschäftlichen Begriffen ("allgegenwärtige Sprache") so weit wie möglich einkapselt - und relevante Aspekte des Geschäfts dem "Programm" aussetzt, ohne dem zuzustimmen Bedürfnisse der Software.

Auf der anderen Seite beschäftigt sich "die Software" mit IO, UI und dergleichen, delegiert jedoch alle Geschäftslogik an das Domänenmodell.

Im Prinzip können Sie Ihr Domänenmodell in einer Assembly einschließen und für mehrere Anwendungen verwenden. Wenn sich Geschäftsregeln ändern, haben sie einen sehr logischen Ort, an dem sie sich auf die Änderungen auswirken können (weil das Modell eine 1: 1 oder fast so repräsentative Darstellung der relevanten Aspekte des Geschäfts ist und mit den gleichen Begriffen wie beschrieben wird das Geschäft).

Answer 2

Die Domäne in DDD muss nicht in OO implementiert werden. Meiner Erfahrung nach ist ein OO-Domänenmodell normalerweise am besten, aber es gibt sehr gute Beispiele für Situationen, in denen dies nicht der Fall ist.

Sie könnten eine Domäne in Regeln implementieren, mit einer Regel-Engine (Beispiel in den Niederlanden, wo dies für eine große Hypothek Anwendung getan wird). Oder Sie tun es in einer funktionalen Sprache. Das Wesentliche ist, dass Ihre Domäne, wie auch immer sie implementiert ist, isoliert ist von dem, was ich normalerweise die technischen Aspekte Ihrer Anwendung nenne (oder, wie die vorherige Antwort es nennt) übergreifende Bedenken, obwohl ich denke, dass es sehr wohl sein kann Querschnittsthemen innerhalb einer Domäne). Eine isolierende Schicht, die unter Verwendung von Adaptern implementiert werden kann, macht die Domäne so weit wie möglich, sogar vollständig, unabhängig von den technischen Gegebenheiten. Diese Ebene nutzt normalerweise Muster wie Facade und Observer.