Wprowadzenie
Niedawno pisałem, że lubię i polecam styl DDD . Dlaczego? Bo nawet jak nie znamy przyszłych zmian (nowych wymagań) to na pewno projekt będzie się dało rozbudować zamiast zmieniać. Dlaczego? Bo jeśli projekt dobrze ?modeluje? rzeczywistość to znaczy, że jeśli tylko coś zmieni się w tej rzeczywistości, to będzie to możliwe do takiego samego odwzorowania w projekcie.
Co piszą inni
Można o tym także przeczytać na blogu MSDN:
Domain Driven Design (DDD) is especially suitable for creating long-term LOB Apps, but usually, DDD is presented as a very patterns & architecture related subject (topics like Bounded-Contexts, Domain-Models, patterns like Repository, Aggregate, Value-Object, etc.), like we actually did in our ?DDD Patterns Guidance with .NET?, but those are not, in fact, the most important topics when really applying DDD. (MSDN Blogs).
O powoli, ale rosnącej, popularności wzorca DDD niech świadczy wspomniane w powyższym artykule “oficjalne” jego wprowadzenie w postaci profilu UML dla Visual Studio 11:
This extension adds a UML profile called DDDProfile, containing the following stereotypes which can be applied to classes, components and interfaces:
aggregate
entity
valueObject
repository
domainService
applicationService
infrastructureService
[…] You should now be able to select these stereotypes on any class, component or interface in that package. (źr. Domain Driven Design UML Stereotypes rozszerzenie).
Wnikliwi pewnie zauważą tu brak wzorca DDD – factory. Nie wiem dlaczego pominięto go w Microsoft, zapewne jego rolę pełni tu prawdopodobnie jeden z trzech elementów Service. Traktuję to jako “problem” semantyczny (jakie znaczenia nadajemy tym nazwom stereotypów) ale “cieszy” mnie, że firma Microsoft jawnie stosuje tego rodzaje wzorce i notacje UML już na etapie analiz i projektowania, bo to znaczy, że formalnie deklaruje użytek z tego typu podejścia.
Co napisałem ja
Opisywałem ostatnio wzorzec DDD jako narzędzie dokumentowania analizy. Faktycznie, czytelnicy mają wiele racji twierdząc, że jest on dość ?bliski implementacji? (a więc zbyt szczegółowy). Dlatego często ?lepszym pomysłem? jest opis logiki systemu na nieco wyższym poziomie abstrakcji pozostawiając tym samym więcej swobody developerowi. W takich przypadkach nie raz używam ogólniejszego wzorca BCE (Boundary, Control, Entity) do modelowania logiki biznesowej, który jest mniej “szczegółowy” (Wzorzec analityczny Boundary Control Entity i ICONIX).
Inną ciekawa propozycja:
Poniżej publikacja zawierająca opis wzorca projektowego: Domain Driven Design oraz Boundary Control Entity. Zawiera również przykłady modeli wykonanych w języku UML.
Pocieszające, że MS dostrzega “momentum” DDD.
Co do zbytniego skupienia na implementacji… Sądzę, że model DDD nie jest zbyt blisko impl – jest odpowiednio.
Jeżeli wyraźnie rozwarstwimy logikę Aplikacją od Domenowej, to w warstwie domenowej nie pojawiają się żądne szczegóły frameworka czy platformy. Model domenowy przekłada się 1-1 na nagłówki metod klas Building Blocks. Jeżeli nawiasy w nagłówkach są zbyt techniczne to można je po prostu pominąć i myśleć o częściach zdania: orzeczeniu i dopełnieniu:)
Jeżeli model jest zbytnio oddalony od formy DDD to pozostawia swobodę analitykowi na przemilczenie niezrozumienia domeny:P Lukę oczywiście zasypuje wówczas developer domyślając się szczegółów – ale zwykle domysły nie są trafione.
Model na poziomie DDD pozwala na: zrozumienie kosztu zmiany – bo zmieniamy wspólny model (a nie “tylko dodajemy checkoboxa na ekranie”) oraz uzmysławia pojęcie “długi technicznego” – np upraszczamy pewne części modelu ze świadomością, że zamykamy go na rozbudowę w tę stronę.
W sumie to mnie pocieszyłeś, bo BCE jest w moich oczach właśnie takim “oddaleniem” od DDD dającym pole do popisu developerowi, który…. wiemy. Często spotykam developerów uzurpujących sobie wyłączne prawo do projektowania modelu dziedziny uznając, że wkraczam w ich kompetencje, jednak często mam wrażenie, że te nie tyle ich kompetencje (bo tych często im właśnie brak) co chęć obrony tezy, że “klasy i cała ta obiektówka to ich zadanie a nie analityka” a praktyka moja jest taka, że po protu upraszczają sobie robotę… niestety – jak słusznie zauważyłeś – zamykając sobie drogę do przyszłej “gładkiej” rozbudowy aplikacji. Niestety to ostatnie to raczej droga w “gwarantowanie” sobie dodatkowych przychodów w przyszłości, ale niestety ma to krótkie nogi…