technology:domainmodel:secondaryindex
Differences
This shows you the differences between two versions of the page.
|
technology:domainmodel:secondaryindex [2013/02/14 19:19] rtavassoli |
technology:domainmodel:secondaryindex [2013/02/18 18:23] (current) rtavassoli |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Sekundärindex - Secondary Index ====== | + | ====== Mengenindex - Set Index ====== |
| - | In DDD heißt es, es gäbe keine secondary indices. Ich behaupte, dass die explizite Verwendung von Zweitindizes eine pragmatische Abweichung von der reinen Anwendung von DDD ist. Durch Zweitindizes kann man den komplizierten Einsatz von Domain Services, SAGAs, Reservation Patterns und Compensating Actions umgehen. Man sollte damit natürlich vorsichtig sein, wobei der übermäßige Einsatz auch nicht schadet, weil ein Zweitindex immer relativ einfach eben durch einen anderen Prozess ersetzt werden kann, der Eventual Consistency verwendet, bzw. sofortige Konsistenz mit dem Reservation Pattern. | + | In DDD heißt es, es gäbe keine transaktional einzuhaltenden, Mengenbasierten Regeln, die mehrere Aggregate umfassen. Ich behaupte, dass die explizite Verwendung von Mengenindizes eine pragmatische Abweichung von der reinen Anwendung von DDD ist. Ein Mengenindex ist im Grunde eine IoC((Inversion of Control)) von Entitäten und Aggregates, indem aus Entitäten Aggregates werden, und die Aggregates auf den Mengenindex((das ursprüngliche Aggregate)) zeigen. Durch Mengenindizes kann man den komplizierten Einsatz von Domain Services, SAGAs, Reservation Patterns und Compensating Actions umgehen. Vor allem aber kann man dieselbe Funktionalität von größeren Aggregates haben, und die Aggregates trotzdem klein halten. Man sollte damit natürlich vorsichtig sein, wobei der übermäßige Einsatz auch nicht schadet, weil ein Mengenindex immer relativ einfach eben durch einen anderen Prozess ersetzt werden kann, der Eventual Consistency verwendet, bzw. sofortige Konsistenz mit dem Reservation Pattern. |
| \\ \\ | \\ \\ | ||
| - | Wenn man sich relativ sicher sein kann, dass ein Aggregte immer gemeinsam mit dem Zweitindex in derselben Partition liegen wird, dann sollte der Einsatz eines Zweit- oder auch Drittindexes auch eine langfristige Lösung darstellen. Die Umsetzung ist relativ einfach - ein paar technische Voraussetzungen müssen eingebaut werden. Dann können Zweitindizes sogar so gebaut werden, dass sie sehr gut in DDD passen, denn dann sind sie nichts anderes als weitere Zweit- und Dritt-Aggregates, die die Ereignisse von anderen Aggregates verwenden. | + | Wenn man sich relativ sicher sein kann, dass ein Aggregte immer gemeinsam mit dem Mengenindex in derselben Partition liegen wird, dann sollte der Einsatz eines Mengenindexes auch eine langfristige Lösung darstellen. Die Umsetzung ist relativ einfach - ein paar technische Voraussetzungen müssen eingebaut werden. Dann können Mengenindizes sogar so gebaut werden, dass sie sehr gut in DDD passen, denn dann sind sie nichts anderes als weitere Zweit- und Dritt-Aggregates, die die Ereignisse von anderen Aggregates verwenden. |
| + | >To-Do: Sekundärindex noch in Mengenindex ändern - nur bis hier erledigt | ||
| ===== Beispiel Zeitdatensätze ===== | ===== Beispiel Zeitdatensätze ===== | ||
| Angenommen die Regeln((Invariants)) sind folgende | Angenommen die Regeln((Invariants)) sind folgende | ||
technology/domainmodel/secondaryindex.1360865961.txt.gz · Last modified: 2013/02/14 19:19 by rtavassoli
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 3.0 Unported
