Słowniczek pojęć bliskoznacznych

Moja żona zainspirowała mnie do tego, aby przerwać strumień notek opisujących jakieś techniczne nowinki, tricki i sztuczki i pochylić się na moment nad tematami bardziej podstawowymi. Czym właściwie jest Domain-Driven Desing? Czym design (projektowanie) różni się od architektury? I czy w ogóle można to w jakiś sensowny sposób wytłumaczyć nie-programiście?

Ostrzegam na wstępie, że niniejsza notka jest wyrazem moich osobistych opinii i nie należy ją traktować jako prawdę objawioną — nie znajduję się w tym momencie w proroczym transie:-)

Architektura

Zacznijmy od wysokiego poziomu abstrakcji. Co rozumiem pod pojęciem architektura? Przede wszystkim dla mnie jest to skrót myślowy prowadzący do architektury oprogramowania. Podczas, gdy istnieje wiele innych dziedzin architektury (jak enterprise architecture), ja ograniczam się w moim blogopisarstwie do tej jednej. Podoba mi się określenie znalezione na tym blogu:

architektura jest rodzajem projektowania, ale nie każde projektowanie to architektura

Architektura oprogramowania, jako zajęcie, to ten podzbiór aktywności projektowych o największym znaczeniu — takich, których skutki są trudne i kosztowne do zmiany.

Jeszcze bardziej jednak podoba mi się inne określenie, zainspirowane artykułem Martina Fowlera. Pomysł polega na tym, że w tworzeniu oprogramowania nie ma narzuconej z góry ważności decyzji: to, czy dana decyzja jest trudna do zmiany,czy nie wynika ze sposobu w jaki budujemy nasz system. Architektura w takim ujęciu jest zestawem metadecyzji: decyzji o tym, które kwestii związanych z projektowaniem systemu mają być trudne do zmiany, a które nie. Wszystko inne (w tym same decyzje) są już  “jedynie” projektowaniem.

Service-Oriented Architecture

SOA to chyba najbardziej chwytliwy trzyliterowy skrót ostatniej dekady. Wszystko, co produkuje nasza branża musi mieć plakietkę “SOA”, aby się sprzedało. Ale czym właściwie jest to całe SOA? Ja mam przynajmniej dwie równoległe teorie. Każda z nich odwołuje się do abstrakcyjnej definicji, zgodnie z którą SOA to architektura, w której centralnym punktem są usługi — autonomiczne (jedna z 4 zasad SOA) byty udostępniające pewne funkcjonalności dla innych podobnych bytów.

SOA “klasyczne”

SOA “wg Thomasa Erla” to dla mnie kwintesencja klasycznego podejścia do usług. W tym rozumieniu katalog usług podzielony jest na warstwy, w obrębie których dominującym wzorcem jest definiowania funkcjonalności usług jest CRUD. Dominującym mechanizmem komunikacji jest zaś synchroniczna komunikacja WS-*. Nie jestem fanem tej definicji. Abstrahując od kwestii technicznych (nie wierzę w efektywność komunikacji synchronicznej), głównym problemem z tak rozumianym SOA są wymagania i założenia organizacyjne.

Pierwsze z nich mówi, że aby SOA było zrealizowane efektywnie, całe przedsiębiorstwo musi być przeanalizowane pod kątem odkrywania usług, które mają się składać na implementację SOA, zanim rozpocznie się jakakolwiek implementacja. Bardzo brzydko pachnie mi to procesami wodospadowymi.

Drugie, jeszcze bardziej problematyczne, założenie sugeruje, że wszystkie usługi powinny posługiwać się tym samym modelem danych w celu zminimalizowania transformacji. Nie zgadzam się z dwóch powodów. Po pierwsze modelowanie danych (a nie zachowania) jest wg mnie mało użyteczne. Po drugie jestem przekonany (a moje przekonanie zbudowane jest na własnym doświadczeniu i lekturze publikacji związanych z DDD), że model powinien rozwiązywać dokładnie jeden problem, dla którego powstał. Model do wszystkiego jest do niczego. Kropka.

Pozostawmy na chwilę SOA i rozważmy inny sposób definiowania architektury…

Event-Driven Architecture

EDA nie jest pomysłem nowym. Nigdy jednak nie zyskała takiego uznania, jak jej siostra, SOA. Architektura oparta o zdarzenia nie jest aż tak napakowana różnymi standardami, wzorcami, dobrymi radami. Jedyne co mówi to, że poszczególne komponenty wchodzące w jej skład porozumiewają się za pomocą zdarzeń mających dobrze określone znaczenie w domenie rozwiązywanego problemu. Żeby nie szukać daleko przykładów, Java-owy Swing posiada architekturę EDA.

SOA wg Udiego Dahana

Wracamy do SOA aby przyjrzeć się wersji, którą proponuje nam Udi Dahan. Jest to architektura spełniająca założenia SOA (tenets), jednak jest także architekturą EDA. Kluczowym elementem tak zdefiniowanej architektury są autonomiczne (a jakże by inaczej) usługi komunikujące się poprzez publikowanie zdarzeń. Zainteresowanych odsyłam do prezentacji “How to avoid failed SOA”, którą Udi prezentował na zeszłorocznym C2C oraz (a może przede wszystkim) do bloga Udiego.

Domain-Driven Design

Schodząc z abstrakcyjnego poziomu architektury na ziemię, stwierdzamy, że coś musi sterować naszym projektowaniem. Na przykład domena — stąd Domain-Driven Design. W odróżnieniu od tego, co się zwykle sądzi, DDD nie jest czymś, co można zrealizować w konkretnym systemie jedynie poprzez wykorzystanie kilku technicznych tricków. DDD jest sposobem pracy zespołów produkcyjnych, który jest zorientowany na modelowanie domeny. To, co zwykle rozumie się pod pojęciem DDD, czyli wszystkie kwestie techniczne, to jedynie wzorzec projektowy Domain Model.

Domain-Driven Design to wiele więcej niż ten wzorzec. Praktyki DDD obejmują sposób rozdziału zadań programistycznych, sposób projektowania implementacji, sposób współpracy między zespołami. DDD wpływa także na architekturę poprzez definiowania map kontekstów i struktur wielkoskalowych wpływających nie tylko na jeden budowany system.

Domain Model

To wzorzec projektowy sugerujący implementację logiki biznesowej w specjalnej warstwie nazywanej modelem domeny. Z modelem związanych jest wiele dobrych praktyk oraz mniejszych wzorców dotyczących m.in. organizacji kodu (na agregaty, encje oraz obiekty ValueObject). Model domeny zwykle składa się z klas reprezentujących jeden-do-jednego byty z przestrzeni biznesowej. Także zwykle jego stan jest trwale przechowywany, za zwyczaj przy pomocy narzędzia mapowania obiektowo-relacyjnego (O/RM).

Domain Events

To jeden z wzorców projektowych związanych z modelem domeny. Dlaczego go wyróżniłem i postanowiłem omówić osobno? Po pierwsze dlatego, że bardzo często się do niego odwołuję w swoich postach. Po drugie, zaś, dlatego, że zdarzenia domenowe często bywają mylone ze zdarzeniami Event-Driven Architecture. Domain Events to sposób na wypychanie informacji z modelu domeny konkretnego systemu. Informacje te mogą, ale nie muszą, zostać później przetransformowane na postać zdarzeń EDA. Równie dobrze mogą zostać przetransformowane na, bardziej klasyczne, asynchroniczne komunikaty. Nic nie stoi temu na przeszkodzie, ponieważ decyzje o użyciu Domain Events i EDA są zupełnie niezależne. Więcej o Domain Events możecie dowiedzieć się tutaj.

To wszystko na dziś. Jeśli macie jakieś pytania lub sugestię co jeszcze w moich postach jest niejasne i wymaga zdefiniowania, zostawcie komentarz.