Warstwy modelu
Jak już wspominałem kilka postów temu, ponowna lektura części Strategic Design z książki Erica Evansa pomogła mi usystematyzować swoją aktualną wiedzę na temat DDD. Dziś chciałbym się z Wami podzielić dalszą częścią mojego odkrycia.
Warstwa możliwości (capabilities) świetnie nadaje się do tworzenia encji warstwy operations.
O co chodzi? Jakiś czas temu Udi Dahan pisał o tym, że nie powinniśmy tworzyć korzeni agregatów. Jego post wykorzystuje przykład sklepu internetowego. Zamiast tworzyć klientów “z powietrza”, sugeruje wprowadzenie koncepcji “witryny referującej” jako korzenia agregatu tworzącego klientów.
Na początku było to dla mnie nieco mgliste. Dlaczego niektóre encje mogą tworzyć inne? Jaki w tym wszystkim jest porządek. Nagle zdałem sobie sprawę, że odpowiedzią są warstwy modelu.
Referrer jest przykładem obiektu warstwy capabilities: ma swoje miejsce w modelu, ale nie uczestniczy aktywnie w codziennym przetwarzaniu. Reprezentuje fizyczny byt umożliwiający funkcjonowanie biznesu — witrynę referującą do naszego sklepu. Customer należy natomiast do warstwy operations — operacje z nim związane są rdzeniem modelu. Logiczne jest więc, że obiekt umożliwiający funkcjonowanie biznesu generuje obiekty codziennej jego aktywności. Tłumacząc to na język modelu: obiekty warstwy capabilities tworzą nowe instancje obiektów operations. Proste, prawda?
Oczywiście, prawidłowość ta nie jest specyficzna jedynie dla modeli sklepów internetowych. Popatrzmy na model aplikacji DDDSample. Rdzeniem modelu domeny są towary (Cargo) i operacje z nimi związane. Towary jednak nie biorą się znikąd — są rejestrowane przez klientów. W tym wypadku obiekt reprezentujący klienta jest częścią warstwy capabilities, natomiast towar — warstwy operations.
Jak zapewne zauważyliście, wprowadzone pojęcie warstw jest dosyć luźne, ponieważ warstwy niższe mają dostęp do obiektów warstw wyższych, i odwrotnie. W tym wypadku (inaczej, niż dla warstw architektury) najważniejsza jest logiczna (a nie fizyczna) separacja koncepcji. Możemy więc sobie pozwolić na taki “luz”.




about 1 year ago
Rozumiem generalnie, ze w ten sposob model komunikuje w inny sposob.
Zastanawiam sie tylko czy naprawde jest powod aby modelizowac to w ten sposob ? Mysle ze dorzucenie dodatkowej encji komplikuje model, zwlaszcza ze jesli chodzi o tworzenie encji i agragatow powinny byc rola serwisow i fabry domeny.
Musze poczytac wiecej na ten temat zanim przyswoje ten koncept
about 1 year ago
W tym temacie wydaje mi się, że jest wiele możliwości. Jedna z nich (omówiona w książce DDD) to właśnie tworzenie obiektów przez new() lub fabryki i zapisywanie w bazie za pomocą repozytoriów.
Jest to dosyć proste podejście (plus), które sam stosuję w niektórych projektach (np. DDDSample). Rozwiązanie przedstawione w tej notce jest wg mnie bardziej espresywne — pokazuje relacje między obiektami. Jak zwykle, coś za coś;)