30 października 2008
Odsłon: 1392
W ostatnim czasie coraz większą popularność wśród projektantów zdobywa metodyka Domain-Driven Design. W artykule tym postaram się krótko opisać co właściwie należy pod tym pojęciem rozumieć, jak projektować aplikacje według wzorców DDD oraz jakie korzyści nam to daje.
Na początku należy zaznaczyć, że Domain-Driven Design ma sens prawdopodobnie tylko dla aplikacji biznesowych (ang. enterprise applications) i to dla nich ta metodyka została stworzona. Co rozumiemy przez to określenie? Jak pisze Martin Fowler w "Patterns of Enterprise Application Architecture" (w polskiej edycji tytuł przetłumaczono niefortunnie jako "Architektura systemów zarządzania przedsiębiorstwem"), trudno byłoby sformułować precyzyjną definicję. Można natomiast pokusić się o próbę podania przykładów na tyle jasnych, że nikt nie będzie miał wątpliwości, czy jego następny projekt również można do tej kategorii zaliczyć. Poniższa tabela prezentuje kilka takich przykładów.
Które rodzaje aplikacji zaliczamy do "biznesowych"?
Jak widać, do grupy aplikacji biznesowych możemy zaliczyć znaczącą większość systemów tworzonych w praktyce w firmach. Możemy podać kilka cech charakterystycznych tego typu projektów:
- zwykle potrzebują utrwalania pewnych danych dotyczących swojego stanu
- ilość danych jest znacząca, często rzędu dziesiątek milionów rekordów
- zazwyczaj umożliwiają dostęp wielu użytkowników jednocześnie
- dysponują skomplikowanym interfejsem użytkownika, złożonym z wielu ekranów
- potrzebują integrować się z innymi aplikacjami biznesowymi
- posiadają złożoną "logikę biznesową"
Termin "logika biznesowa" ująłem w cudzysłów, gdyż - zabawne - niewiele jest na świecie rzeczy mniej logicznych niż właśnie "logika biznesowa". Jest to zestaw tych reguł, wymagań i procesów, które my, jako twórcy oprogramowania, otrzymujemy od klientów i nie podlegają one dyskusji z naszej strony. Zwykle związane są ze sposobem działania firmy klienta i biznesu, który tworzona aplikacja ma wspierać. Typowa reguła biznesowa może być przykładowo wyrażona przez zdanie: jeżeli klient zakupił produkty na łączną kwotę wyższą niż 1000 złotych, to przysługuje mu zniżka 10%. Logika biznesowa jest istotą aplikacji i faktycznie jedynym celem jej istnienia. Cała reszta służy do rozwiązywania problemów natury technicznej, czyli: utrwalania danych, ich transportu oraz interakcji z użytkownikami i innymi systemami.
Przejdźmy teraz do meritum, czyli: czym jest Domain-Driven Design? Sam termin pochodzi z książki Erica Evansa pt. "Domain Driven-Design: Tackling Complexity in the Heart of Software", wydanej w 2003 roku przez Addison Wesley (znakomite wydawnictwo, nawiasem mówiąc). W opracowaniu tym Evans przedstawił zbiór zasad projektowania aplikacji biznesowych, które jego zdaniem znacznie zwiększają szanse powodzenia projektów, a także ich żywotność. Punktem wyjścia dla Evansa było założenie, że kluczowym elementem systemu jest właśnie logika biznesowa i to ona powinna stać w centrum procesu wytwarzania oprogramowania. Logika w postaci modelu dziedziny (ang. domain model) powinna być niezależna od pozostałych elementów, takich jak infrastruktura czy UI, aby mogła być rozwijana bez konieczności uwzględniania problemów technologicznych, a jej migracja na nową infrastrukturę - nieunikniona przecież przy większych systemach - mogła być przeprowadzona bez żadnych większych modyfikacji.
Diagnoza, wydawałoby się, skądś już znana - i faktycznie, autor nie wymyślił tutaj wiele nowego. Usystematyzował jedynie znane problemy, zebrał najlepsze dla nich rozwiązania (wzorce i praktyki), oraz nadał im zbiorczą, elegancką nazwę. Nie umniejsza to oczywiście zasług Evansa i jego poprzedników, a żeby się o tym przekonać, wystarczy obejrzeć niemal dowolny system w wybranej firmie, rozwijany od kilku lat. Bez wątpienia znajdziemy w nim liczne elementy brutalnie łamiące powyższe zasady. Najwyraźniej niezbędne jest ponowne uświadomienie projektantom zasad tworzenia porządnych systemów.
Nie bez winy są tutaj twórcy narzędzi programistycznych i frameworków. Przez lata reklamowali nam swoje produkty jako ostateczne rozwiązania i za każdym razem po paru latach trzeba było migrować systemy na coś jeszcze nowszego i jeszcze lepszego, bez możliwości tworzenia bogatej, niezależnej logiki biznesowej, która - rozproszona po wszystkich warstwach systemu - za każdym razem sprawiała ogromne problemy przy migracji. Najnowsze dzieło Microsoft, czyli Entity Framework, również zawodzi pod tym względem na całej linii, o czym niedawno pisałem. Z drugiej strony, coś ostatnio wyraźnie się zmienia, DDD coraz bardziej zyskuje na popularności i producenci również to dostrzegają. Z Microsoft i zespołem od Entity Framework włącznie.
Znamy już zatem diagnozę, ale pozostaje pytanie: jak to wszystko zrealizować? Wielu z nas (choć nie wszyscy) intuicyjnie dostrzega, że ten SQL wklepany w obiektach biznesowych i "ośmiotysięczniki" reguł w procedurach składowanych w bazie to nie jest ani trochę dobre rozwiązanie. Ale jak można zrobić to inaczej? Jak zrealizować te słuszne postulaty w praktycznym projekcie? Jak tworzyć systemy wysokiej jakości, które są elastyczne i testowalne, bez utraty zalet podejścia "klasycznego", bez utraty wydajności i skalowalności? Odpowiedzi na te pytania istnieją i Evans je przedstawia. Wymaga to pewnego wysiłku edukacyjnego oraz zastosowania odpowiednich wzorców i narzędzi, a nawet specyficznego podejścia do całego procesu wytwarzania oprogramowania, ale efekt końcowy warty jest tego poświęcenia.
Naszym celem jest tworzenie dobrych projektów bez utraty zalet istniejących systemów
To tyle na początek. Zaprezentowałem na razie tylko zarys problemu i wspomniałem o kierunku, w którym należy podążać aby go rozwiązać. W kolejnych częściach wejdę głębiej w zasady Domain-Driven Design i przedstawię sposoby ich realizacji w praktyce. Spróbuję pokazać, jak rozwiązać podstawowe problemy zarówno na poziomie architektury, jak i w szczegółach implementacji. Skorzystam też z kilku popularnych wzorców i technik, takich jak: Test-Driven Development, Inversion of Control, Dependency Injection czy Aspect-Oriented Programming, a także praktyk "zwinnego" wytwarzania oprogramowania (Agile) i spróbuję połączyć je z DDD, aby osiągnąć możliwie najlepsze efekty.
PS. Na temat DDD niemal na pewno będę pisał częściej, gdyż będzie to silnie związane z moją pracą magisterską. Niecierpliwym polecam natomiast wersję skróconą książki Evansa, dostępną za darmo w serwisie InfoQ: Domain-Driven Design Quickly (wymaga rejestracji).