Tytuł oryginału: Implementing Domain-Driven Designpdf.helion.pl/dddaro/dddaro.pdf · Mimo to możemy sięgnąć wyżej — po dobrze zaprojektowany model oprogra-mowania, który

Tytuł oryginału: Implementing Domain-Driven Design

Tłumaczenie: Radosław Meryk

Projekt okładki: Studio Gravite / OlsztynObarek, Pokoński, Pazdrijowski, Zaprucki

ISBN: 978-83-283-2547-0

Authorized translation from the English language edition, entitled: IMPLEMENTING DOMAIN-DRIVEN DESIGN; ISBN 0321834577; by Vaughn Vernon; published by Pearson Education, Inc, publishing as Addison Wesley.Copyright © 2013 Pearson Education, Inc.

All rights reserved. No part of this book may by reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc.Polish language edition published by HELION S.A. Copyright © 2016.

Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji.

Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli.

Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce.

Wydawnictwo HELIONul. Kościuszki 1c, 44-100 GLIWICEtel. 32 231 22 19, 32 230 98 63e-mail: [email protected]: http://helion.pl (księgarnia internetowa, katalog książek)

Materiały graficzne na okładce zostały wykorzystane za zgodą Shutterstock Images LLC.

Pliki z przykładami omawianymi w książce można znaleźć pod adresem: ftp://ftp.helion.pl/przyklady/dddaro.zip

Drogi Czytelniku!Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/dddaroMożesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.

Printed in Poland.

• Kup książkę• Poleć książkę • Oceń książkę

• Księgarnia internetowa• Lubię to! » Nasza społeczność

http://helion.pl/rt/dddaro

http://helion.pl/rf/dddaro

http://helion.pl/ro/dddaro

http://helion.pl

http://ebookpoint.pl/r/4CAKF

Spis tre ciS owo wst pne ............................................................................................... 15Przedmowa .................................................................................................... 17Podzi kowania ............................................................................................... 29O autorze ...................................................................................................... 33Przewodnik po tej ksi ce .............................................................................. 35

Rozdzia 1. Wprowadzenie w DDD .............................................................. 43Czy mog zastosowa DDD? .......................................................................... 44Dlaczego nale y stosowa DDD? ................................................................... 49W jaki sposób stosowa DDD? ....................................................................... 64Warto biznesowa u ywania technik DDD ................................................... 70

1. Organizacja zyskuje przydatny model swojej dziedziny .......................... 712. Powstaje udoskonalona i dok adna definicja biznesu ............................. 713. Eksperci dziedziny przyczyniaj si do tworzenia projektu

oprogramowania .................................................................................. 724. U ytkownicy zyskuj system wygodniejszy do u ywania ........................ 725. Wokó modeli tworzone s czytelne granice ........................................... 736. Architektura przedsi biorstwa jest lepiej zorganizowana ........................ 737. Stosowane jest zwinne, iteracyjne, ci g e modelowanie ......................... 738. Wykorzystywane s nowe narz dzia, zarówno na poziomie strategicznym,

jak i taktycznym ................................................................................... 74Wyzwania zwi zane ze stosowaniem DDD ..................................................... 74Fikcja z du dawk realizmu ......................................................................... 84Podsumowanie .............................................................................................. 87

Rozdzia 2. Dziedziny, Poddziedziny i Konteksty Ograniczone .................... 89Szeroka perspektywa ...................................................................................... 90

Poddziedziny i Konteksty Ograniczone w akcji .......................................... 90Dziedzina G ówna w centrum uwagi ........................................................ 96

Dlaczego projektowanie strategiczne jest tak wa ne? ...................................... 99wiat prawdziwych Dziedzin i Poddziedzin .................................................. 103

Nadawanie sensu Kontekstom Ograniczonym .............................................. 109Nie tylko model ..................................................................................... 114Rozmiar Kontekstów Ograniczonych ....................................................... 116Zrównanie z komponentami technicznymi .............................................. 119

Przyk adowe Konteksty ................................................................................ 120Kontekst Wspó praca .............................................................................. 121Kontekst To samo i Dost p .................................................................. 128Kontekst Zarz dzanie Projektem Agile ..................................................... 130

Podsumowanie ............................................................................................ 133

Kup książkę Poleć książkę





10 SP I S T R E CI

Rozdzia 3. Mapy Kontekstu ...................................................................... 135Dlaczego Mapy Kontekstu s takie wa ne? ...................................................136

Rysowanie Mapy Kontekstu ....................................................................138Projekty i relacje organizacyjne ...............................................................140Sporz dzenie mapy trzech Kontekstów ....................................................143

Podsumowanie .............................................................................................160

Rozdzia 4. Architektura ............................................................................ 163Wywiad z cz owiekiem sukcesu — CIO firmy SaaSOvation ..........................165Warstwy ......................................................................................................170

Zasada Odwracania Zale no ci ...............................................................174Architektura Sze ciok tna albo Porty i Adaptery ...........................................176Architektura ukierunkowana na us ugi .........................................................181REST (Representational State Transfer) .......................................................185

REST jako styl architektoniczny ..............................................................185Najwa niejsze cechy serwera HTTP typu RESTful ...................................187Najwa niejsze cechy klienta HTTP typu RESTful ....................................188REST i DDD ...........................................................................................189Dlaczego REST? ......................................................................................190

CQRS (Command-Query Responsibility Segregation) ..................................191Analiza obszarów wzorca CQRS ..............................................................193Obs uga ostatecznie spójnego modelu zapyta .........................................200

Architektura Sterowana Zdarzeniami ...........................................................201Potoki i Filtry .........................................................................................203Procesy D ugotrwa e (Sagi) .....................................................................208Magazynowanie Zdarze .........................................................................215Przetwarzanie rozproszone z wykorzystaniem magazynów

Data Fabric i Grid .............................................................................219Replikacja danych ...................................................................................220Magazyny Fabric sterowane zdarzeniami a Zdarzenia Dziedziny ..............221Ci g e Zapytania ....................................................................................222Przetwarzanie rozproszone ......................................................................223

Podsumowanie .............................................................................................224

Rozdzia 5. Encje ........................................................................................ 227Do czego u ywamy Encji? ............................................................................228Unikatowa to samo ...................................................................................229

Identyfikator dostarczany przez u ytkownika ..........................................230Identyfikator generowany przez aplikacj ................................................232Identyfikator generowany przez mechanizm utrwalania ...........................236Identyfikator przypisany przez inny Kontekst Ograniczony ......................239Kiedy ma znaczenie czas generowania identyfikatora? .............................241To samo zast pcza ...............................................................................243Stabilno to samo ci .............................................................................246

Odkrywanie Encji i ich cech wrodzonych .....................................................249Odkrywanie Encji i ich w a ciwo ci ........................................................250Wyszukiwanie podstawowych zachowa .................................................254Role i obowi zki .....................................................................................259Konstrukcja ............................................................................................264






SP I S T R E CI 11

Walidacja ............................................................................................... 266ledzenie zmian ...................................................................................... 275

Podsumowanie ............................................................................................ 276

Rozdzia 6. Obiekty Warto ci ..................................................................... 277Cechy Warto ci ........................................................................................... 279

Mierzy, okre la ilo ciowo albo opisuje ..................................................... 279Niezmienno ......................................................................................... 280Poj ciowa Ca o ................................................................................... 281Zast powalno ...................................................................................... 284Równo Warto ci .................................................................................. 286Zachowanie Pozbawione Skutków Ubocznych ......................................... 287

Minimalizm integracji .................................................................................. 292Typy Standardowe wyra ane w formie Warto ci .......................................... 293Testowanie Obiektów Warto ci ................................................................... 299Implementacja ............................................................................................. 303Utrwalanie Obiektów Warto ci .................................................................... 309

Unikaj niepotrzebnego Wyciekania Modelu Danych ................................ 310ORM i pojedyncze Obiekty Warto ci ....................................................... 311Mapowanie ORM i wiele Warto ci serializowanych

w pojedynczej kolumnie .................................................................... 314Mechanizm ORM i wiele Warto ci dostarczanych

za pomoc encji bazy danych ............................................................ 315ORM i wiele Warto ci dostarczanych za pomoc z czenia tabel .............. 320Frameworki ORM i obiekty Enum reprezentuj ce Stan ............................ 321

Podsumowanie ............................................................................................ 324

Rozdzia 7. Us ugi ...................................................................................... 325Czym jest Us uga Dziedziny (a przede wszystkim czym ona nie jest)? ............ 327Upewnij si , e potrzebujesz Us ugi .............................................................. 329Modelowanie us ugi w dziedzinie ................................................................ 333

Czy wydzielony interfejs jest konieczny? ................................................. 335Proces oblicze ....................................................................................... 338Us ugi transformacji ............................................................................... 341Pos ugiwanie si miniwarstw Us ug Dziedziny ....................................... 341

Testowanie Us ug ........................................................................................ 341Podsumowanie ............................................................................................ 344

Rozdzia 8. Zdarzenia Dziedziny ................................................................ 347Kiedy i dlaczego warto korzysta ze Zdarze Dziedziny? .............................. 347Modelowanie Zdarze ................................................................................. 351

Zdarzenia z cechami Agregatu ................................................................. 356To samo .............................................................................................. 357

Publikowanie Zdarze z Modelu Dziedziny ................................................. 359Wydawca ............................................................................................... 359Subskrybenci .......................................................................................... 363

Rozpowszechnianie wiadomo ciw odleg ych Kontekstach Ograniczonych ............................................... 365Spójno infrastruktury obs ugi komunikatów ......................................... 366Autonomiczne Us ugi i Systemy .............................................................. 367Tolerancje opó nie ............................................................................... 369






12 SP I S T R E CI

Magazyn Zdarze ........................................................................................370Style architektoniczne wysy ania zmagazynowanych Zdarze .......................375

Publikowanie powiadomie w postaci zasobów RESTful .........................375Publikowanie powiadomie za pomoc warstwy middleware

obs ugi komunikatów ........................................................................380Implementacja ..............................................................................................382

Publikowanie obiektów NotificationLog .................................................383Publikowanie powiadomie bazuj cych na komunikatach .......................387

Podsumowanie .............................................................................................395

Rozdzia 9. Modu y .................................................................................... 397Projektowanie z u yciem Modu ów ..............................................................398Podstawowe konwencje nazewnictwa Modu ów ...........................................401Konwencja nazewnictwa Modu ów w modelu ..............................................402Modu y Kontekstu Zarz dzanie Projektem Agile ..........................................404Modu y w innych warstwach .......................................................................407Modu przed Kontekstem Ograniczonym .....................................................409Podsumowanie .............................................................................................409

Rozdzia 10. Agregaty ................................................................................ 411Zastosowanie Agregatów wewn trz Dziedziny G ównej Scrum .....................412

Pierwsza próba: Agregat w formie wielkiego klastra .................................413Druga próba: wiele Agregatów ................................................................415

Regu a: rzeczywiste niezmienniki modelu w granicach spójno ci ..................418Regu a: projektuj ma e Agregaty ..................................................................420

Nie ufaj wszystkim przypadkom u ycia ...................................................423Regu a: odwo uj si do innych Agregatów

za pomoc identyfikatora to samo ci ......................................................424Wspomaganie wspólnego dzia ania Agregatów

dzi ki referencjom ich identyfikatorów ..............................................426Nawigowanie po modelu ........................................................................426Skalowalno i dystrybucja .....................................................................429

Regu a: na zewn trz granicy u ywaj spójno ci ostatecznej ............................429Zapytaj, czyje to zadanie ........................................................................432

Powody amania regu ..................................................................................433Powód numer 1: wygoda interfejsu u ytkownika .....................................433Powód numer 2: brak mechanizmów technicznych ..................................434Powód numer 3: transakcje globalne .......................................................435Powód numer 4: wydajno zapyta .......................................................435Przestrzeganie regu .................................................................................436

Pozyskiwanie informacji przez odkrywanie ...................................................436Ponowna analiza projektu .......................................................................436Szacowanie kosztu Agregatu ....................................................................438Powszechne scenariusze u ycia ................................................................439Zu ycie pami ci ......................................................................................441Analiza projektu alternatywnego .............................................................442Implementacja spójno ci ostatecznej .......................................................443Czy to jest zadanie cz onka zespo u? .......................................................445Czas na decyzje .......................................................................................446






SP I S T R E CI 13

Implementacja ............................................................................................. 447Utworzenie Encji G ównej z unikatowym identyfikatorem to samo ci ..... 447Faworyzowanie Obiektów Warto ci ........................................................ 449Wykorzystanie prawa Demeter oraz techniki „Powiedz, nie pytaj” ........... 449Optymistyczna wspó bie no ................................................................ 452Unikaj wstrzykiwania zale no ci ............................................................. 454

Podsumowanie ............................................................................................ 455

Rozdzia 11. Fabryki .................................................................................. 457Fabryki w modelu dziedziny ........................................................................ 457Metody Fabrykuj ce wewn trz Rdzenia Agregatu ........................................ 459

Tworzenie egzemplarzy obiektów CalendarEntry .................................... 460Tworzenie egzemplarzy obiektu Discussion ............................................. 463

Fabryki na poziomie Us ug ........................................................................... 465Podsumowanie ............................................................................................ 467

Rozdzia 12. Repozytoria ........................................................................... 469Repozytoria typu kolekcja ............................................................................ 470

Implementacja z wykorzystaniem Hibernate ........................................... 476Rozwa ania na temat implementacji bazuj cej na frameworku TopLink .... 484

Repozytoria typu trwa y magazyn ................................................................ 486Implementacja z wykorzystaniem systemu Coherence ............................. 488Implementacja na bazie MongoDB .......................................................... 494

Dodatkowe zachowanie ............................................................................... 499Zarz dzanie transakcjami ............................................................................. 501

Ostrze enie ............................................................................................ 506Hierarchie typów ......................................................................................... 506Repozytoria a Obiekty Dost pu do Danych .................................................. 509Testowanie Repozytoriów ........................................................................... 511

Testowanie z wykorzystaniem implementacji w pami ci .......................... 514Podsumowanie ............................................................................................ 517

Rozdzia 13. Integrowanie Kontekstów Ograniczonych ............................. 519Podstawy integracji ...................................................................................... 520

Systemy rozproszone s zasadniczo ró ne ................................................ 521Wymienianie informacji poza granicami systemów .................................. 522

Integracja z wykorzystaniem zasobów RESTful ............................................ 529Implementacja zasobu RESTful ............................................................... 530Implementacja klienta REST z wykorzystaniem

Warstwy Zapobiegaj cej Uszkodzeniom ............................................. 533Integracja z wykorzystaniem mechanizmu przekazywania komunikatów ...... 539

Zapewnienie dop ywu informacjio w a cicielach produktu i cz onkach zespo u .................................... 540

Czy mo na przydzieli odpowiedzialno ? ............................................... 546D ugotrwa e procesy i unikanie odpowiedzialno ci .................................. 551Maszyny stanu procesu i mechanizmy ledzenia limitu czasu ................... 563Projektowanie bardziej zaawansowanych procesów ................................. 573Gdy infrastruktura komunikatów lub system s niedost pne ................... 576

Podsumowanie ............................................................................................ 577






14 SP I S T R E CI

Rozdzia 14. Aplikacja ............................................................................... 579Interfejs u ytkownika ...................................................................................582

Renderowanie Obiektów Dziedziny .........................................................583Renderowanie obiektów transferu danych

na podstawie egzemplarzy Agregatów ................................................584U ycie Mediatora do publikowania wewn trznego stanu Agregatu ...........585Renderowanie egzemplarzy Agregatów na podstawie obiektów DPO ........586Reprezentacje stanu egzemplarzy Agregatu ...............................................587Zapytania do Repozytorium zoptymalizowane dla przypadków u ycia .....588Obs uga wielu odmiennych klientów .......................................................588Adaptery renderowania i obs uga edycji u ytkownika ..............................589

Us ugi Aplikacji ............................................................................................592Przyk ad Us ugi Aplikacji ........................................................................593Oddzielone wyj cie us ugi .......................................................................599

Kompozycja wielu Kontekstów Ograniczonych ............................................603Infrastruktura ...............................................................................................605Kontenery komponentów .............................................................................606Podsumowanie .............................................................................................609

Dodatek A. Agregaty i ród a Zdarze : A+ES ........................................... 611Wewn trz Us ugi Aplikacji ...........................................................................613Handlery Polece .........................................................................................621Sk adnia lambda ...........................................................................................625Zarz dzanie wspó bie no ci ........................................................................626Swoboda struktury przy zastosowaniu wzorca A+ES ....................................630Wydajno ...................................................................................................630Implementacja Magazynu Zdarze ...............................................................633Utrwalanie z wykorzystaniem relacyjnej bazy danych ....................................637Utrwalanie obiektów BLOB .........................................................................639Agregaty ukierunkowane ..............................................................................641Rzutowanie odczytów modelu ......................................................................642Zastosowanie cznie z projektem bazuj cym na Agregatach .........................644Wzbogacanie Zdarze ..................................................................................645Narz dzia i wzorce pomocnicze ...................................................................647

Serializatory Zdarze ..............................................................................647Niezmienno Zdarze ............................................................................649Obiekty Warto ci ....................................................................................649

Generowanie kontraktu ...............................................................................652Testy jednostkowe i specyfikacje ..................................................................653Wsparcie dla wzorca A+ES w j zykach funkcyjnych .....................................655

Bibliografia ................................................................................................ 657

Skorowidz .................................................................................................. 661






Rozdział 1.

Wprowadzenie w DDDProjekt nie jest tylko tym, jak rzecz wygląda i jakie sprawia wrażenie.

Projekt opisuje to, jak ona działa.

— Steve Jobs

Pracując nad oprogramowaniem, staramy się, by było ono wysokiej jakości. Pewnąjakość osiągamy poprzez zastosowanie testów, które pomagają nam dostarczaćoprogramowanie bez olbrzymiej liczby błędów. Jednakże, nawet jeśli moglibyśmystworzyć oprogramowanie zupełnie wolne od błędów, samo to niekoniecznieoznacza, że zaprojektowany model oprogramowania jest wysokiej jakości. Modeloprogramowania — sposób, w jaki oprogramowanie wyraża rozwiązanie poszu-kiwanego problemu biznesowego — w dalszym ciągu może mieć istotne wady.Dostarczanie oprogramowania z małą liczbą defektów jest oczywiście dobre.Mimo to możemy sięgnąć wyżej — po dobrze zaprojektowany model oprogra-mowania, który jawnie odzwierciedla zamierzony cel biznesowy — a nasza pracamoże nawet osiągnąć poziom doskonały.

Podejście rozwoju oprogramowania określane jako Domain-Driven Design,albo DDD, istnieje po to, by było nam łatwiej odnieść sukces w tworzeniu wyso-kiej jakości projektów modelu oprogramowania. Jeśli metodyka DDD zostanieprawidłowo zaimplementowana, pomaga osiągnąć punkt, w którym nasz projektdokładnie prezentuje sposób, w jaki działa oprogramowanie. Celem tej książki jestudzielenie czytelnikom pomocy w prawidłowej implementacji DDD.

Może DDD jest dla Ciebie zupełną nowością. Być może już próbowałeś posłu-żyć się DDD i przychodziło Ci to z trudem, a może wcześniej skutecznie zasto-sowałeś tę metodykę. Niezależnie od okoliczności bez wątpienia czytasz tęksiążkę dlatego, że chcesz poprawić swoje umiejętności implementacji DDD —i możesz to osiągnąć. „Mapa drogowa” rozdziału pomoże Ci zaspokoić Twoje spe-cyficzne potrzeby.

Mapa drogowa rozdziału

• Podczas zmagań ze złożonością sprawdzisz, co Twoim projektom i zespołommoże zaoferować DDD.

• Dowiesz się, jak ocenić projekt, by się przekonać, czy zasługuje on na zainwe-stowanie w DDD.




44 Rozdzia 1 . WPRO WA D Z E NI E W DDD

• Rozwa ysz popularne alternatywy dla DDD i zastanowisz si , dlaczego ich stoso-wanie cz sto prowadzi do problemów.

• Nauczysz si podstaw DDD przy okazji zapoznawania si z pierwszymi krokamiw projekcie, które powiniene zrobi .

• Dowiesz si , jak przekaza zalety metodyki DDD kierownictwu, ekspertom dzie-dziny i technicznym uczestnikom projektu.

• Staniesz wobec wyzwa stosowania DDD uzbrojony w wiedz o tym, jak mo eszodnie sukces.

• Przyjrzysz si zespo owi, który uczy si sposobów implementacji DDD.

Czego powiniene oczekiwa od DDD? Nie jest to trudny, skomplikowany,ceremonialny proces, który blokuje drog do post pów. Zamiast tego oczekuj sto-sowania zwinnych technik projektowania, którym prawdopodobnie ju zaufa e .Poza tym przygotuj si na poznanie metod, które pomagaj zyska g boki wgl dw Twoj dziedzin biznesow . Jednocze nie daj perspektyw stworzenia modelioprogramowania, które s testowalne, elastyczne, uwa nie zorganizowane i sta-rannie wykonane. S po prostu wysokiej jako ci.

DDD daje nam narz dzia zarówno do modelowania strategicznego, jak i tak-tycznego. Narz dzia te s konieczne do projektowania wysokiej jako ci oprogra-mowania, które spe nia podstawowe cele biznesowe.

Czy mog zastosowa DDD?Mo esz zastosowa DDD, je eli masz:

pasj do tworzenia doskona ego oprogramowania codziennie oraz upór, byosi gn ten cel;

gorliwo do nauki i osi gania post pów oraz hart ducha, aby przyzna si dotego, e jest Ci to potrzebne;

zdolno ci do rozumienia wzorców oprogramowania oraz sposobów ich prawi-d owego stosowania;

umiej tno ci i cierpliwo do odkrywania alternatywnych projektów z wyko-rzystaniem sprawdzonych zwinnych metod wytwarzania oprogramowania;

odwag do stawiania wyzwa stanowi istniej cemu;

pragnienie zwracania uwagi na szczegó y i umiej tno ich dostrzegania orazupodobanie do eksperymentowania i odkrywania;

motywacj do szukania sposobów na lepsze i bardziej inteligentne kodowanie.






CZ Y M O G ZASTOS OWA DDD? 45

Nie chc powiedzie , e krzywa nauki nie istnieje. Mówi c otwarcie, krzywanauki bywa stroma. Pomimo to niniejsza ksi ka powsta a, aby pomóc sp aszczyt krzyw tak bardzo, jak to mo liwe. Moim celem jest udzielenie czytelnikowii jego zespo owi pomocy w zastosowaniu metodyki DDD oraz zmaksymalizo-waniu szans na odniesienie sukcesu.

DDD przede wszystkim nie dotyczy technologii. Podstawowe zasady DDD to:dyskusja, s uchanie, zrozumienie, odkrywanie i warto biznesowa — wszystkopo to, aby scentralizowa wiedz . Je eli masz zdolno rozumienia biznesu, w któ-rym dzia a Twoje przedsi biorstwo, to zgodnie z planem minimum mo esz uczest-niczy w procesie odkrywania modelu oprogramowania w celu stworzenia J zykaWszechobecnego. Oczywi cie b dziesz musia nauczy si o biznesie wi cej —znacznie wi cej. Mimo to jeste na dobrej drodze do odniesienia sukcesu z DDD,poniewa potrafisz rozumie poj cia swojego biznesu podczas rozwijania opro-gramowania, a to tworzy w a ciw podstaw do zastosowania DDD w ca ymprocesie.

Czy posiadanie wieloletniego do wiadczenia w rozwoju oprogramowania jestpomocne? By mo e. Niemniej jednak do wiadczenie w rozwijaniu oprogra-mowania nie daje zdolno ci s uchania i uczenia si od ekspertów dziedziny —ludzi, którzy wiedz najwi cej na temat obszarów biznesu o wysokim prioryte-cie. Najwi cej mo na skorzysta z rozmów z osobami, które rzadko u ywajtechnicznego argonu (lub nigdy tego nie robi ). Trzeba nauczy si uwa nie ichs ucha . Trzeba uszanowa ich punkt widzenia i zaufa , e znaj temat znacznielepiej ni my sami.

Zaanga owanie ekspertów dziedziny przynosi du e korzy ci

Mo na du o skorzysta na rozmowach z osobami, które rzadko u ywaj technicznegoargonu (lub nigdy tego nie robi ). Nie tylko Ty b dziesz uczy si od nich. Istnieje

du e prawdopodobie stwo, e oni tak e b d uczyli si od Ciebie.

Jedn z bardziej warto ciowych cech DDD jest to, e eksperci dziedziny rów-nie musz pos ucha Ciebie. Jeste cie cz onkami tego samego zespo u. Chociamo e si to wydawa dziwne, eksperci dziedziny nie wiedz wszystkiego o swoimbiznesie i oni te powinni dowiedzie si o nim wi cej. Nie tylko Ty b dzieszsi uczy od nich. Istnieje du e prawdopodobie stwo, e oni tak e b d uczylisi od Ciebie. Twoje pytania o to, co oni wiedz , najprawdopodobniej spowo-duj równie odkrycie tych obszarów, które nie s im znane tak samo dobrze.B dziesz bezpo rednio zaanga owany w pomoc wszystkim osobom w zespolew zdobywaniu g bszego zrozumienia biznesu — mo na nawet powiedzie :kszta towania biznesu.

To wspaniale, kiedy zespó uczy si i rozwija razem. Je eli dasz temu szans ,metodyka DDD to umo liwi.







Nie mamy ekspertów dziedziny

Ekspert dziedziny to nie jest tytu zawodowy. Ekspertami dziedziny s ludzie, którzybardzo dobrze znaj obszar biznesu, w którym pracujesz. Cz sto maj oni obszernwiedz w dziedzinie biznesowej. Zazwyczaj s to projektanci produktu albo osobyz dzia u sprzeda y.

Nie zwracaj uwagi na nazwy stanowisk. Poszukiwani przez Ciebie ludzie o dzie-dzinie, w której pracujesz, wiedz wi cej ni ktokolwiek inny i na pewno znaczniewi cej ni Ty. Znajd ich. Pos uchaj. Naucz si czego od nich. Uwzgl dnij ich zda-nie w projekcie kodu.

Dotychczas osi gn li my gotowo do spokojnego startu. Nie chcia bym jed-nak powiedzie , e umiej tno ci techniczne s niewa ne — e s czym , bez czegomo na si oby . Trzeba si zapozna z zaawansowanymi poj ciami z zakresumodelowania dziedziny w oprogramowaniu. Nie oznacza to jednak, e b dziemyzmuszeni robi co , co jest ponad nasze si y. Je li Twoje umiej tno ci mieszczsi gdzie pomi dzy wiedz z ksi ki Head First Design Patterns [Freeman et al.]a oryginaln zawarto ci pozycji Design Patterns [Gamma et al.] lub je li znaszbardziej zaawansowane wzorce, to masz naprawd du e szanse na odniesieniesukcesu z DDD. Mo esz na to liczy . B d robi wszystko, co w mojej mocy,aby sta o si to mo liwe. B d si stara „obni a poprzeczk ”, niezale nie od tego,jaki jest wyj ciowy poziom do wiadczenia czytelnika.

Co to jest Model Dziedziny?To model oprogramowania bardzo okre lonej dziedziny biznesowej, w której pra-cujesz. Cz sto jest on zaimplementowany jako model obiektowy, w którym obiektyzawieraj zarówno dane, jak i zachowania w harmonii z dok adnym znaczeniem biz-nesowym.

Stworzenie unikatowego, uwa nie zaprojektowanego Modelu Dziedziny, stano-wi cego sedno podstawowej, strategicznej aplikacji albo podsystemu, ma zasadnicze zna-czenie dla stosowania metodologii DDD. Dzi ki u yciu DDD Modele Dziedziny b dmniej rozbudowane i bardzo skoncentrowane. Stosuj c DDD, nigdy nie próbujemyzamodelowa ca ego przedsi biorstwa biznesowego w pojedynczym, olbrzymim ModeluDziedziny. To jest dobre!

Warto rozwa y wymienione poni ej perspektywy osób, które mog skorzy-sta na stosowaniu DDD. Wiem, e czytelnik pasuje do jednej z tych grup.

Nowicjusz, m odszy deweloper: „Jestem m ody, ze wie ymi pomys ami. Mammnóstwo energii do kodowania i chc mie wp yw na projekt. Zdenerwo-wa mnie jeden z projektów, w którym bra em udzia . Nie oczekiwa em, eten mój pierwszy »koncert« poza kampusem studenckim b dzie oznaczaprzerzucanie szufl danych w t i z powrotem, przy wykorzystaniu wielu pra-wie identycznych, a jednak redundantnych obiektów. Dlaczego ta architekturajest tak z o ona, skoro w oprogramowaniu dzieje si tak niewiele? Dlaczego






CZ Y M O G ZASTOS OWA DDD? 47

tak jest? Kiedy staram si modyfikowa kod, ulega on cz stym awariom.Czy kto w a ciwie rozumie, co on powinien robi ? Mam teraz kilka z o onychnowych funkcji do dodania. Regularnie tworz adaptery wokó istniej cychklas, d c do tego, by unikn kiczu. adna przyjemno . Jestem pewien,e jest co , co mog zrobi poza kodowaniem i debugowaniem dzie i noc

tylko po to, aby doko czy iteracje. Cokolwiek to jest, b d si stara to zna-le i pozna . Us ysza em rozmowy kilku osób na temat DDD. To brzmi jakGang Czterech, ale dostosowany do modelu dziedziny. Doskonale”.

Musz si z tym zapozna .

rednio zaawansowany deweloper: „Kilka ostatnich miesi cy sp dzi em przynowym projekcie. Moj rol jest stworzenie ró nicy. Rozumiem, co si dziejew projekcie, ale brakuje mi g bokiej wiedzy, kiedy spotykam si ze star-szymi deweloperami. Wydaje mi si , e niektóre sprawy przebiegaj le, ale niejestem pewien, dlaczego tak jest. Mam zamiar pomóc zmieni sposób, w jakis realizowane funkcje. Wiem, e zastosowanie okre lonej technologii do roz-wi zania problemu pozwala dotrze tylko do pewnego miejsca. Ogólnie rzeczbior c, to nie jest wystarczaj co daleko. Potrzebuj zdrowej techniki rozwojuoprogramowania, która pomo e mi sta si m drym i do wiadczonym twórcoprogramowania. Jeden ze starszych architektów, nowa osoba w projekcie,wspomnia o metodologii, która nazywa si DDD. Postanowi em si temuprzys ucha ”.

W tym momencie mówisz ju jak do wiadczony programista. Kontynuujlektur . Twoje nastawienie i „my lenie do przodu” b d nagrodzone.

Starszy deweloper, architekt: „U ywa em metodyki DDD w kilku projektach,ale odk d obj em nowe stanowisko, jeszcze jej nie stosowa em. Lubi mo li-wo ci wzorców taktycznych, lecz móg bym osi gn znacznie wi cej, wykorzy-stuj c projektowanie strategiczne. Kiedy czyta em [Evans], najwi ksze wra eniewywar na mnie J zyk Wszechobecny. To pot ne narz dzie. Dyskutowa emz kilkoma kolegami z mojego zespo u i z kierownictwa, staraj c si wp ynna ich pogl d na temat zastosowania DDD. Perspektywy u ycia tej metodykibudz ogromne podekscytowanie jednego z nowych cz onków zespo u, a tak ekilku rednio zaawansowanych i starszych programistów. Kierownictwo niepodziela tego entuzjazmu. Do czy em do tej firmy niedawno i chociaotrzyma em zadanie bycia liderem, to wydaje si , e organizacja jest zainte-resowana wprowadzaniem gwa townych usprawnie w mniejszym stopniu,ni my la em. Wszystko jedno. I tak nie rezygnuj . Je li uzyskam poparcieinnych deweloperów, to wiem, e b dziemy w stanie razem to osi gn .Korzy ci b d znacznie wi ksze ni oczekiwania. Zaprosimy ludzi zajmuj -cych si wy cznie biznesem — ekspertów dziedziny — do bli szej wspó pracyz zespo ami technicznymi i rzeczywi cie zainwestujemy w nasze rozwi zania,zamiast ogranicza si wy cznie do ich produkowania — iteracja po iteracji”.







To jest dok adnie to, co powinien robi lider. W tej ksi ce zamieszczonomnóstwo wskazówek, które pokazuj , jak odnie sukces, stosuj c projekto-wanie strategiczne.

Ekspert dziedziny: „Uczestnicz w specyfikowaniu rozwi za IT naszychbiznesowych wyzwa ju od d ugiego czasu. By mo e oczekuj zbyt wiele,ale chcia bym, eby deweloperzy lepiej rozumieli, co my tutaj robimy. Zaw-sze rozmawiaj z nami tak, jakby my byli nierozgarni ci. Nie rozumiej , egdyby nie by o nas, to oni nie mieliby nic do roboty ze swoimi komputerami.Deweloperzy zawsze w jaki dziwny sposób mówi o tym, co robi nasze opro-gramowanie. Je eli mówimy o A, oni mówi , e to tak naprawd nazywa si B.Wydaje mi si , e powinni my mie jaki rodzaj s ownika lub mapy drogowejzawsze wtedy, gdy chcemy powiedzie , czego potrzebujemy. Je li nie pozwa-lamy deweloperom dzia a po swojemu, tzn. u ywa nazwy B w odniesieniudo czego , co my znamy jako A, to przestaj wspó pracowa . Tracimy w tensposób mnóstwo czasu. Dlaczego oprogramowanie nie mo e dzia a dok ad-nie tak, jak prawdziwi eksperci my l o biznesie?”.

Dobrze to uj e . Jednym z najwi kszych problemów jest fa szywa potrzebat umaczenia przekazu pomi dzy lud mi biznesu a pracownikami technicznymi.Ten rozdzia jest dla Ciebie. Jak si przekonasz, DDD stawia ekspertów dzie-dziny i deweloperów na tym samym poziomie.

I jeszcze niespodzianka! Niektórzy deweloperzy ju sk aniaj si w Twojstron . Pomó im w tym.

Mened er: „Dostarczamy oprogramowanie. Efekty nie zawsze s zgodnez oczekiwaniami, a wprowadzanie zmian zwykle zajmuje wi cej czasu, nipowinno. Deweloperzy stale mówi co o jakiej dziedzinie. Nie jestem pewien,czy powinni my koncentrowa si na kolejnej technice albo metodologii,s dz c, e b dzie ona rodzajem srebrnej kuli. S ysza em to wcze niej ju tysi crazy. Próbujemy, entuzjazm zanika i znów wracamy do starego. Ci gle powta-rzam, e powinni my trzyma kurs i przesta marzy , ale zespó mnie naciska.Pracuj ci ko, wi c powinienem ich wys ucha . S inteligentnymi lud mii zas uguj na szans usprawnienia rzeczywisto ci. Je li jej im nie dam, zde-nerwuj si i odejd . Móg bym im da troch czasu na nauk i dostrojenie sido nowej techniki, gdybym dosta zielone wiat o z wy szego szczebla zarz -dzania. My l , e móg bym zyska t aprobat , gdybym móg przekonamojego szefa do twierdze zespo u o kluczowej inwestycji w oprogramowa-nie i centralizacji wiedzy biznesowej. Prawd jest, e moja praca by aby atwiej-sza, gdybym móg co zrobi , by wzbudzi zaufanie i ch wspó pracy pomi dzymoimi zespo ami a ekspertami biznesowymi. W ka dym razie s ysz , e w a-nie to mog zrobi ”.

Dobry mened er!






DL A C Z EGO N AL E Y ST OSO W A DDD? 49

Kimkolwiek jeste , powiniene wzi pod uwag wa ne ostrze enie. Abyodnie sukces z DDD, b dziesz musia si czego nauczy . B dzie du o tegoczego . Nie powinno to by jednak trudne. Jeste m dry i musisz uczy si przezca y czas. Pomimo wszystko ka dy z nas musi sprosta nast puj cemu wyzwaniu:

Osobi cie jestem zawsze gotowy, by si uczy ,chocia nie zawsze lubi , gdy kto mnie poucza.

— Sir Winston Churchill

Ta ksi ka ma w a nie taki cel: stara em si , by nauczanie by o tak przyjemne,jak to mo liwe, i by zapewnia o wiedz niezb dn do skutecznego zastosowaniatechnik DDD.

Czytelnik móg by jednak postawi pytanie: „Dlaczego nale y stosowa DDD?”.To dobre pytanie.

Dlaczego nale y stosowa DDD?W a ciwie ju wcze niej poda em kilka dobrych powodów, dla których zasto-sowanie DDD ma tak bardzo praktyczny sens. Ryzykuj c z amanie zasady DRY(ang. Don’t Repeat Yourself — dos . nie powtarzaj si ), ponownie przytocz je w tymmiejscu oraz dodam do nich kilka nowych powodów. Czy kto s ysza echo?

Umie ekspertów dziedziny i deweloperów na tym samym poziomie. Dzi kitemu wytworzone oprogramowanie b dzie mia o sens tak e dla ludzi biznesu,a nie tylko dla koderów. Nie oznacza to jedynie tolerowania przeciwnej grupy.Oznacza stworzenie jednego spójnego i zwi z ego zespo u.

Fraza „ma sens dla ludzi biznesu” oznacza zainwestowanie w biznes poprzezstworzenie oprogramowania, które maksymalnie b dzie przypomina sys-tem, jaki stworzyliby biznesowi liderzy i eksperci dziedziny, gdyby sami bylikoderami.

Mo emy nauczy wszystkich cz onków zespo u wi cej o biznesie. adenekspert dziedziny, aden mened er szczebla C, nikt i nigdy nie wie wszystkiegona temat biznesu. Poznawanie biznesu jest sta ym procesem odkrywania, któryz czasem staje si coraz bardziej wnikliwy. Dzi ki zastosowaniu DDD wszy-scy si ucz , poniewa ka dy co wnosi do odkrywczych dyskusji.

Centralizowanie wiedzy ma znaczenie kluczowe, gdy dzi ki temu mo nazagwarantowa , e rozumienie oprogramowanie nie b dzie zamkni t „wiedzplemienn ”, dost pn tylko dla kilku wybra ców — zazwyczaj deweloperów.







Nie ma niepotrzebnych t umacze przekazu pomi dzy ekspertami dziedziny,deweloperami oprogramowania a oprogramowaniem. Nie oznacza to, e ist-nieje kilka t umacze . Oznacza to dok adnie zero t umacze , poniewa zespórozwija wspólny j zyk, którym pos uguj si wszyscy jego cz onkowie.

Projekt jest kodem, a kod jest projektem. Projekt opisuje to, jak system dzia a.Poznawanie najlepszych projektów kodu nast puje poprzez szybkie do wiad-czalne modele tworzone z wykorzystaniem zwinnych procesów odkrywania.

Metodologia DDD dostarcza solidnych technik rozwoju oprogramowania,które dotycz projektu zarówno na poziomie strategicznym, jak i taktycznym.Projekt strategiczny pomaga nam zrozumie , co stanowi najwa niejsz inwe-stycj w oprogramowanie, jakie istniej ce zasoby oprogramowania mo nawykorzysta , aby zrealizowa j najszybciej i najbezpieczniej, oraz jakie osobypowinny by w ni zaanga owane. Projekt taktyczny pomaga w utworzeniupojedynczego, eleganckiego modelu rozwi zania z wykorzystaniem przete-stowanych bloków budulcowych oprogramowania.

Tak jak ka da dobra inwestycja, która ma przynie du e korzy ci, z zasto-sowaniem metodologii DDD wi si pewne pocz tkowe koszty dotycz ce czasui wysi ków zespo u. Bior c pod uwag typowe wyzwania, jakie napotykamyw ka dym przedsi wzi ciu zwi zanym z rozwojem oprogramowania, potrzebainwestowania w solidn metodologi wytwarzania oprogramowania wydaje siszczególnie wa na.

Dostarczanie warto ci biznesowych mo e by ulotneRozwijanie oprogramowania, które dostarcza prawdziwej warto ci dla biznesu,nie jest tym samym co rozwijanie zwyk ego biznesowego oprogramowania. Opro-gramowanie dostarczaj ce prawdziwej warto ci biznesowej mo na porówna zestrategicznymi inicjatywami w biznesie; przynosi ono rozwi zania, w którychmo na wyra nie zidentyfikowa konkurencyjn przewag — oprogramowanie,którego sednem nie jest technologia, ale biznes.

Wiedza biznesowa nigdy nie jest scentralizowana. Zespo y programistów muszzachowa równowag pomi dzy potrzebami i daniami wielu interesariuszyoraz okre li ich priorytety, a ponadto zaanga owa wiele osób o ró norodnychumiej tno ciach. Celem wszystkich tych przedsi wzi powinno by odkrywa-nie funkcjonalnych i niefunkcjonalnych wymaga stawianych oprogramowaniu.Jak po zebraniu wszystkich tych informacji mo na uzyska pewno , e okre lonewymaganie dostarcza prawdziwej warto ci biznesowej? Jak si dowiedzie , jakichwarto ci biznesowych szukamy, jak je odkrywamy, nadajemy im priorytety i jerealizujemy?

Jednym z najbardziej dotkliwych problemów podczas realizowania zadaz zakresu rozwoju oprogramowania biznesowego jest luka pomi dzy ekspertami







dziedziny a deweloperami oprogramowania. Ogólnie rzecz bior c, prawdziwieksperci dziedziny s skupieni na dostarczaniu warto ci biznesowych. Z drugiejstrony deweloperzy oprogramowania s zwykle skoncentrowani na technologiioraz technicznych rozwi zaniach problemów biznesowych. Nie oznacza to, edeweloperzy oprogramowania maj nieodpowiednie motywacje. Chodzi o to, eto technika przyci ga ich uwag . Nawet kiedy deweloperzy oprogramowaniazaczynaj wspó pracowa z ekspertami dziedziny, to wspó praca przebiega g ów-nie powierzchownie, a w tworzonym oprogramowaniu zazwyczaj stosowane st umaczenia (odwzorowania) zwi zane z tym, w jaki sposób my li ekspert dzie-dziny, i tym, jak to interpretuje deweloper oprogramowania. Powsta e w tensposób oprogramowanie zazwyczaj nie odzwierciedla rozpoznawalnej realizacjimentalnego modelu ekspertów dziedziny albo robi to tylko cz ciowo. Z czasemten rozd wi k staje si kosztowny. T umaczenie wiedzy dziedzinowej na opro-gramowanie gubi si , gdy deweloperzy przechodz do innych projektów lubodchodz z firmy.

Inny, cho powi zany z poprzednim, problem powstaje w sytuacji, kiedyeksperci dziedziny nie zgadzaj si ze sob . To si czasami zdarza, poniewaka dy ekspert ma mniej b d wi cej do wiadczenia w okre lonej modelowanejdziedzinie, a niekiedy s to eksperci z powi zanych ze sob , ale jednak innychobszarów. Typowy dla wielu ekspertów dziedziny jest równie brak wiedzy spe-cjalistycznej z zakresu okre lonej dziedziny. Czasem si zdarza, e tacy „eksperci”s w wi kszym stopniu analitykami biznesowymi, cho oczekuje si od nichrzeczowego wk adu w dyskusj . Gdy taka sytuacja wymknie si spod kontroli,w rezultacie zamiast ostrych powstaj rozmyte modele mentalne — co prowa-dzi do koliduj cych ze sob modeli oprogramowania.

Jeszcze gorsza sytuacja wyst puje w przypadku, gdy zastosowanie technicznegopodej cia do rozwoju oprogramowania powoduje z zmian sposobu, w jakidzia a biznes. Chocia jest to troch inny scenariusz, to dobrze znane s sytu-acje, gdy wdro enie oprogramowania ERP zmienia ogólny sposób dzia ania biz-nesu w organizacji, tak by dopasowa si do sposobu funkcjonowania oprogra-mowania ERP. Ca kowitego kosztu posiadania ERP nie mo na w pe ni obliczyw kategoriach op at licencyjnych i konserwacyjnych. Reorganizacja i zak óceniedzia ania biznesu mog by o wiele bardziej kosztowne ni obydwa wymienioneczynniki namacalne. Podobna dynamika wyst puje w sytuacji, kiedy zespó roz-woju oprogramowania interpretuje potrzeby biznesowe i przekszta ca je na fak-tyczne dzia ania powstaj cego oprogramowania. Dla biznesu, klientów firmyi jej partnerów mo e to powodowa powstanie zarówno kosztów, jak i zak ócew pracy. Co wi cej, ta techniczna interpretacja jest i niepotrzebna, i mo liwado unikni cia. Wystarczy zastosowa sprawdzone techniki wytwarzania oprogra-mowania. Rozwi zanie to jest kluczow inwestycj .







W jaki sposób pomaga DDD?DDD jest podej ciem do rozwijania oprogramowania, które skupia si na nast -puj cych trzech najwa niejszych aspektach:

1. DDD czy ze sob ekspertów dziedziny i deweloperów oprogramowania,stawiaj c przed nimi zadanie wytwarzania oprogramowania, które odzwier-ciedla model mentalny ekspertów biznesowych. Nie oznacza to skoncentro-wania wysi ków na modelowaniu „rzeczywistego wiata”. Zamiast niego DDDdostarcza model, który jest najbardziej przydatny dla biznesu. Czasami przy-datne i realistyczne modele przenikaj si wzajemnie, ale do momentu, w któ-rym te modele si rozchodz , DDD stosuje model najbardziej u yteczny.

Bior c pod uwag ten cel, eksperci dziedziny i deweloperzy oprogramowa-nia wspólnie rozwijaj J zyk Wszechobecny tych obszarów biznesu, które smodelowane. J zyk Wszechobecny jest rozwijany przy akceptacji ca egozespo u. Cz onkowie zespo u porozumiewaj si nim i jest on bezpo redniouwzgl dniony w modelu oprogramowania. Warto powtórzy , e zespó sk adasi zarówno z ekspertów dziedziny, jak i deweloperów oprogramowania.Nigdy nie jest tak, e s „my” i „oni”. Zespó to zawsze my. To jest kluczowawarto biznesowa, która pozwala przetrwa specjalistycznej wiedzy bizne-sowej d u ej, ni trwaj stosunkowo krótkie pocz tkowe prace rozwojowezwi zane z kilkoma pierwszymi wersjami oprogramowania. Wiedza ta trwatak e d u ej, ni istniej zespo y, które to oprogramowanie wytworzy y. Tojest element, który udowadnia, e koszt rozwoju oprogramowania jest uza-sadnion inwestycj biznesow , a nie tylko zwyk ym kosztem.

Podejmowany wysi ek jednoczy ekspertów dziedziny, którzy pocz tkowo niezgadzaj si ze sob albo nie maj podstawowej wiedzy z zakresu dziedziny.Co wi cej, praca nad oprogramowaniem wzmacnia spójno zespo u dzi kirozpowszechnianiu obszernej wiedzy dziedzinowej w ród wszystkich cz on-ków zespo u, w tym deweloperów oprogramowania. Wysi ki projektowemo na uzna za szkolenie mówi ce o tym, e ka da firma powinna inwesto-wa w swoich pracowników sektora wiedzy.

2. DDD zajmuje si strategicznymi inicjatywami biznesu. Chocia to strate-giczne podej cie do projektowania w naturalny sposób zawiera analiz tech-niczn , to w wi kszym stopniu skupia si na strategicznym kierunku biznesu.Pomaga to zdefiniowa najlepsze wewn trzzespo owe relacje organizacyjnei dostarcza system wczesnego ostrzegania, pozwalaj cy rozpozna sytuacje,w których okre lona relacja mog aby spowodowa niepowodzenie oprogra-mowania, a nawet ca ego projektu. Celem technicznych aspektów projek-towania strategicznego jest czytelne wytyczenie granic systemów i obszarówbiznesowych, co pozwala chroni wszystkie us ugi na poziomie biznesu. Todostarcza istotnych motywów do osi gni cia ogólnej architektury ukierun-kowanej na us ugi lub architektury sterowanej wzgl dami biznesowymi.







3. DDD wychodzi naprzeciw rzeczywistym technicznym wymaganiom opro-gramowania poprzez wykorzystanie narz dzi projektowania taktycznego doanalizy i rozwoju wykonywalnych produktów oprogramowania. Narz dziaprojektowania taktycznego pozwalaj deweloperom produkowa oprogra-mowanie, które jest poprawn kodyfikacj mentalnego modelu ekspertówdziedziny. Jest ono wysoce testowalne, mniej podatne na b dy (tworzy twier-dzenie, które da si udowodni ), zgodne z umowami dotycz cymi zapewnie-nia jako ci us ug (SLA) i skalowalne, a tak e umo liwia wykonywanie roz-proszonych oblicze . Ogólnie rzecz bior c, najlepsze praktyki DDD dotyczkilkunastu wysokopoziomowych aspektów architektury oraz ni szych pozio-mów projektu. G ówny akcent k ad one na rozpoznawanie rzeczywistychregu biznesowych i niezmienników danych oraz na ochron przed wyst -powaniem b dów.

Stosowanie tego podej cia w rozwoju oprogramowania pozwala wszystkimcz onkom zespo u skutecznie dostarcza rzeczywist warto biznesow .

„Mocowanie si ” ze z o ono ci dziedzinyMetod DDD chcemy u y g ównie w tych obszarach, które s najwa niejsze dlabiznesu. Nie inwestujemy w to, co mo e by atwo zast pione. Inwestujemy w nie-trywialne, bardziej z o one komponenty. Najbardziej warto ciowe i najwa niej-sze rzeczy, które daj najwi ksze szanse na osi gni cie zysków. W a nie dlategonazywamy taki model Dziedzin G ówn (2). To w a nie ona oraz, w dalszejkolejno ci, wa niejsze Poddziedziny Pomocnicze (2) zas uguj na najwi kszeinwestycje i je otrzymuj . W zwi zku z tym bez w tpienia nale a oby si dowie-dzie , co to znaczy „z o ony”.

U ywaj DDD, aby upraszcza , a nie komplikowa

Metod DDD nale y u ywa do modelowania z o onych dziedzin w najprostszy mo -liwy sposób. Nigdy nie nale y stosowa DDD, by bardziej skomplikowa istniej cerozwi zanie.

To, co mo na okre li jako „z o one”, b dzie ró ne dla ró nych rodzajówbiznesu. Ró ne firmy maj ró ne wyzwania, ró ne poziomy dojrza o ci i ró nezdolno ci rozwijania oprogramowania. Dlatego zamiast ustalania tego, co jestz o one, atwiejsze mo e by okre lenie tego, co jest nietrywialne. A zatem Twójzespó i kierownictwo powinni ustali , czy system, nad którym planujecie pra-cowa , zas uguje na poniesienie kosztów zwi zanych z inwestycj w DDD.

Karty punktów DDD. Aby ustali , czy okre lony projekt kwalifikuje si dozainwestowania w DDD, mo na skorzysta z tabeli 1.1. Je eli opis w wierszuna karcie punktów pasuje do Twojego projektu, umie odpowiedni liczbpunktów w kolumnie po prawej stronie. Policz wszystkie punkty dla swojego pro-jektu. Je li jest ich 7 albo wi cej, powa nie si zastanów nad korzystaniem z DDD.






Tab

ela

1.1.

Kar

ty p

unkt

ów D

DD

Czy

Tw

ój p

roje

kt u

zysk

a 7

lub

wi

cej p

unkt

ów?

Jeel

i Tw

ój p

roje

kt...

Punk

tyU

wag

i pom

ocni

cze

Tw

ójw

ynik

Jeel

i Tw

oja

aplik

acja

jest

w c

ao

ci s

konc

entr

owan

a na

dan

ych

i kw

alifi

kuje

si d

o za

stos

owan

ia c

zyst

ego

rozw

iza

nia

CR

UD

, gdz

ie k

ada

ope

racj

a je

stza

sadn

iczo

pro

stym

zap

ytan

iem

baz

y da

nych

w c

elu

stw

orze

nia,

odc

zyta

nia,

zakt

ualiz

owan

ia a

lbo

usun

ici

a re

kord

u, to

nie

pot

rzeb

ujes

z D

DD

. Tw

ójze

spó

pow

inie

n je

dyni

e op

raco

wa

wyg

odny

inte

rfej

s do

edy

tora

tab

elba

zy d

anyc

h. M

ówi

c in

acze

j, je

eli m

oes

z za

ufa

sw

oim

uyt

kow

niko

m,

e b

d p

raw

idow

o w

prow

adza

li da

ne b

ezpo

redn

io d

o ta

beli,

akt

ualiz

owal

ije

i cz

asam

i usu

wal

i, to

nie

pot

rzeb

ujes

z na

wet

inte

rfej

su u

ytko

wni

ka.

Tak

i sce

nari

usz

nie

jest

rea

listy

czny

, ale

mo

na g

o so

bie

wyo

braz

i. J

eli

dost

wor

zeni

a ro

zwi

zani

a m

ona

uy

pro

steg

o na

rzdz

ia d

o pr

ogra

mow

ania

aplik

acji

bazo

dano

wyc

h, t

o ni

e w

arto

mar

now

a c

zasu

i pi

eni

dzy

firm

yna

zas

toso

wan

ie D

DD

.

0C

ho w

ydaj

e si

to o

czyw

iste,

odr

óni

enie

cze

go, c

o je

stpr

oste

, od

zo

oneg

o ni

e za

wsz

e je

st a

twe.

To

nie

jest

tak,

e

kada

apl

ikac

ja, k

tóre

nie

jest

czy

stym

rozw

iza

niem

CR

UD

, zas

uguj

e na

cza

s i w

ysie

kw

oon

e w

stos

owan

ie D

DD

. W z

wi

zku

z ty

m n

ieki

edy

trze

ba u

y in

nych

met

ryk,

któ

re p

ozw

ol n

arys

owa

lini

pom

idz

y ty

m, c

o je

st z

oon

e, a

tym

, co

zo

one

nie

jest

.

Jeel

i Tw

ój s

yste

m w

ymag

a w

ykon

ania

tyl

ko 3

0 (a

lbo

mni

ej)

oper

acji

bizn

esow

ych,

to

jest

pra

wdo

podo

bnie

do

pro

sty.

Ozn

acza

oby

to,

e w

Tw

ojej

apl

ikac

ji by

oby

czni

e ni

e w

ice

j ni

30

hist

oryj

ek u

ytko

wni

ków

lub

e ap

likac

ja w

ykor

zyst

uje

prze

pyw

y sp

raw

, a k

ady

z ty

ch p

rzep

ywów

obej

muj

e ty

lko

min

imal

ny z

akre

s lo

giki

biz

neso

wej

. Je

li m

ona

szy

bko

i at

wo

stw

orzy

tak

apl

ikac

j, u

ywaj

c R

uby

on R

ails

alb

o G

roov

y i G

rails

,i j

eli

brak

kon

trol

i nad

zo

ono

ci i

zmia

nam

i nie

nas

trcz

a C

i pro

blem

ów,

to T

wój

syst

em p

raw

dopo

dobn

ie n

ie p

otrz

ebuj

e za

stos

owan

ia D

DD

.

1D

la ja

sno

ci: m

am n

a m

yli

oko

o 25

– 3

0 po

jedy

nczy

chm

etod

biz

neso

wyc

h, a

nie

25

– 30

kom

plet

nych

inte

rfej

sów

us

ugow

ych,

z k

tóry

ch k

ady

obe

jmuj

ew

iele

met

od. T

en d

rugi

sys

tem

mo

e by

zo

ony.






Mo

na z

atem

pow

iedz

ie,

e je

li sy

stem

zaw

iera

30

– 40

his

tory

jek

uyt

kow

nika

alb

o pr

zep

ywów

spr

aw, t

o za

czyn

a by

zo

ony.

W ta

kim

przy

padk

u T

wój

syst

em z

aczy

na z

mie

rza

w k

ieru

nku

obsz

aru

zajm

owan

ego

prze

z D

DD

.

2O

strz

een

ie: b

ardz

o cz

sto

zo

ono

nie

jest

rozp

ozna

wan

aw

ysta

rcza

jco

wcz

eni

e. M

y, d

ewel

oper

zy o

prog

ram

owan

ia,

jest

em

y na

praw

d d

obrz

y w

nie

doce

nian

iu z

oon

oci

i poz

iom

u w

ysik

u. S

amo

to,

e m

amy

ocho

t s

twor

zyap

likac

j R

ails

alb

o G

rails

, wca

le n

ie z

nacz

y,e

pow

inni

my.

W d

usz

ej p

ersp

ekty

wie

mo

eto

bar

dzie

j zas

zkod

zi n

i p

omóc

.

Naw

et je

li ap

likac

ja n

ie je

st z

oon

a te

raz,

to c

zy je

j zo

ono

mo

e w

zros

n?

Mo

emy

nie

wie

dzie

tego

na

pew

no d

o cz

asu,

a p

raw

dziw

i uyt

kow

nicy

aplik

acji

zacz

n je

j uyw

a. W

kol

umni

e „U

wag

i pom

ocni

cze”

zam

iesz

czon

oop

is c

zynn

oci

, któ

re m

og p

omóc

w o

dkry

ciu

praw

dziw

ej s

ytua

cji.

Nal

ey

tu z

acho

wa

ost

rono

. Je

eli i

stni

ej ja

kiek

olw

iek

prze

san

kico

do

tego

, e

aplik

acja

ma

naw

et u

mia

rkow

an z

oon

o —

to je

st d

obre

mie

jsce

, by

by tr

och

par

anoi

kiem

— m

oe

to b

y w

ysta

rcza

jcy

zna

kte

go,

e b

dzie

ona

bar

dzie

j ni

um

iark

owan

ie z

oon

a. W

tym

prz

ypad

kupo

win

nim

y si

sk

oni

ku

DD

D.

3W

tym

prz

ypad

ku o

pac

a si

prz

eana

lizow

a z

eks

pert

ami

dzie

dzin

y b a

rdzi

ej z

oon

e sc

enar

iusz

e u

ycia

i zo

bacz

y,

dok

d to

zap

row

adzi

. Czy

eks

perc

i dzi

edzi

ny:

ju p

rosz

o b

ardz

iej z

oon

e ce

chy

funk

cjon

alne

?W

taki

m r

azie

istn

ieje

pra

wdo

podo

bie

stw

o,e

aplik

acja

ju te

raz

albo

wkr

ótce

sta

nie

si z

byt

zo

ona,

by

mo

na b

yo

uyw

a p

odej

cia

CR

UD

;

s ta

k zn

udze

ni c

echa

mi f

unkc

jona

lnym

i, e

ledw

iezn

osz

kon

iecz

no ic

h om

awia

nia?

Pra

wdo

podo

bnie

aplik

acja

nie

jest

zo

ona.

Cec

hy fu

nkcj

onal

ne a

plik

acji

prze

z la

ta b

d s

i c

zst

o zm

ieni

a. T

rudn

opr

zew

idzi

e, c

zy te

zm

iany

bd

pro

ste.

4Z

asto

sow

anie

DD

D m

oe

pom

óc w

zar

zdz

aniu

zo

ono

ci re

fakt

oryz

acji

mod

elu

w m

iar

up

ywu

czas

u.

Nie

roz

umie

sz D

zied

ziny

(2),

poni

ewa

jest

now

a. Z

tego

, co

wie

cie

Ty

i cz

onko

wie

Tw

ojeg

o ze

spo

u, n

ikt

tego

wcz

eni

ej n

ie z

robi

.N

ajpr

awdo

podo

bnie

j ozn

acza

to,

e

aplik

acja

jest

zo

ona

albo

przy

najm

niej

zas

uguj

e na

uw

an

ana

liz z

mie

rzaj

c d

o ok

rele

nia

pozi

omu

zo

ono

ci.

5T

rzeb

a po

prac

owa

z e

kspe

rtam

i dzi

edzi

nyi p

oeks

pery

men

tow

a z

mod

elam

i, by

opr

acow

a te

nw

aci

wy.

Na

pew

no te

prz

ypis

ae

pun

kty

w je

dnym

albo

kilk

u po

prze

dnic

h kr

yter

iach

, wi

c za

stos

uj D

DD

.







To wiczenie zwi zane z punktacj mog o doprowadzi Twój zespó do nast -puj cych wniosków:

To le, e nie mo emy szybko i atwo zmieni biegu, gdy odkryjemy, e znajdu-jemy si po niew a ciwej stronie z o ono ci, niezale nie od tego, czy niew a ciwastrona jest mniej, czy bardziej z o ona, ni s dzili my.

To oczywiste, ale oznacza tylko to, e musimy osi gn lepsz sprawno w okre-laniu prostoty i z o ono ci we wczesnej fazie planowania projektu. To pozwoli

zaoszcz dzi nam du o czasu, kosztów i k opotów.

Kiedy podejmiemy wa n decyzj architektoniczn i mocno zaanga ujemy siw rozwój kilku przypadków u ycia, z pewno ci b dziemy mocno zablokowanizastosowan architektur . Lepiej dokonywa m drych wyborów odpowiedniowcze nie.

Je eli która z tych obserwacji pasuje do Twojego zespo u, oznacza to, e robiszw a ciwy u ytek z krytycznego my lenia.

Anemia i utrata pami ciAnemia mo e by powa n dolegliwo ci zdrowotn z niebezpiecznymi skutkamiubocznymi. Gdy po raz pierwszy w literaturze pojawi si termin AnemicznyModel Dziedziny (ang. Anemic Domain Model) [Fowler, Anemic] nie mia onoznacza pozytywnej cechy. To tak, jakby powiedzie , e model dziedziny, któryjest s aby, bez wrodzonych behawioralnych mocnych stron, móg by by czymdobrym. O dziwo Anemiczne Modele Dziedziny pojawi y si w naszej bran y.K opot w tym, e wi kszo deweloperów uwa a je za ca kiem normalne i nawetnie przyznaje, e w systemach korzystaj cych z takich modeli istnieje powa nyproblem. Ale to jest prawdziwy problem.

Zastanawiasz si nad tym, czy Twój model jest „zm czony”, „apatyczny”,„zapomina”, jest „niezdarny” i „potrzebuje klepni cia w rami ”? Je eli nagledo wiadczasz technicznej hipochondrii, to nadszed w a ciwy moment na prze-prowadzenie samobadania. Albo si uspokoisz, albo potwierdzisz swoje najgorszeobawy. W celu przeprowadzenia badania wykonaj czynno ci zapisane w tabeli 1.2.

Jakich odpowiedzi udzieli e ?

Je eli odpowiedzia e „nie” na oba pytania, Twój model dziedziny ma si ca -kiem dobrze.

Je eli odpowiedzia e „tak” na oba pytania, Twój model dziedziny jest bardzo,bardzo chory. To jest anemia. Dobra wiadomo jest taka, e mo esz mupomóc, je li b dziesz kontynuowa lektur .

Je eli odpowiedzia e „tak” na jedno pytanie i „nie” na drugie, to albo zaprze-czasz sam sobie, albo cierpisz na z udzenia lub inne neurologiczne dolegli-wo ci, których przyczyn mo e by anemia. Co powiniene zrobi , je li odpo-






DL A C Z EGO N AL E Y ST OSO WA DDD? 57

Tabela 1.2. Okre lenie historii zdrowia modelu dziedziny

Tak/nie

Czy w Twoim oprogramowaniu, które nazywasz modelem dziedziny,w wi kszo ci wyst puj publiczne gettery i settery i nie ma lub prawienie ma adnej logiki biznesowej — tzn. wyst puj obiekty, które w wi kszo cis kontenerami warto ci atrybutów?

Czy komponenty oprogramowania, które cz sto u ywaj Twojego modeludziedziny, s tymi, w których wyst puje wi kszo logiki biznesowejTwojego systemu i które wykorzystuj cz sto publiczne gettery i setterymodelu dziedziny? Prawdopodobnie nazywasz t konkretn warstwklienta modelu dziedziny Warstw Us ug albo Warstw Aplikacji (4, 14).Je eli zamiast tego opisuje to Twój interfejs u ytkownika, odpowiedz „tak”na to pytanie i napisz tysi c razy na tablicy, e nigdy wi cej tego nie zrobisz.

Wskazówka: w a ciwe odpowiedzi to albo „tak” na oba pytania, albo „nie”na oba pytania.

wiedzi koliduj ze sob ? Od razu przejd do pierwszego pytania i ponownieuruchom samosprawdzenie. Nie spiesz si , ale pami taj, e odpowiedzi na obapytania powinno by dobitne „tak!”.

Zgodnie z tym, co powiedzia Fowler [Fowler, Anemic], Anemiczny ModelDziedziny jest z y, poniewa wymaga poniesienia wysokich kosztów rozwijania mo-delu dziedziny, a w zamian uzyskujemy niewiele korzy ci albo wr cz nie uzysku-jemy adnych. Na przyk ad ze wzgl du na niedopasowanie obiektowo-relacyjnedeweloperzy takiego modelu dziedziny po wi caj zbyt du o czasu i wysi ku namapowanie obiektów do trwa ego magazynu i w drug stron . To wysoka ce-na, jak trzeba zap aci , podczas gdy w zamian otrzymujemy niewiele korzy cilub nie uzyskujemy ich wcale. Dodam, e to, czym dysponujemy, w ogóle nie jestmodelem dziedziny, a tylko modelem danych zrzutowanym z modelu relacyjnego(albo innego modelu bazodanowego) na obiekty. To jest oszukany modeldziedziny, któremu w a ciwie bli ej do definicji Aktywnego Rekordu [Fowler,P of EAA]. Najprawdopodobniej tak architektur mo na upro ci . Wystarczyzrezygnowa z pretensjonalno ci i przyzna , e w istocie u ywamy pewnejformy Skryptu Transakcji [Fowler, P of EAA].

Przyczyny anemiiJe eli wi c Anemiczny Model Dziedziny jest chorym rezultatem straconegowysi ku projektowego, to dlaczego tak wielu deweloperów go stosuje, my l c,e ich model znajduje si w doskona ym zdrowiu? Na pewno to odzwierciedla

mentalno programowania proceduralnego, ale nie s dz , aby to by najwa niej-szy powód. Wielu deweloperów z naszej bran y to na ladowcy przyk adów kodu,co w gruncie rzeczy nie jest z e, o ile przyk ady s wysokiej jako ci. Cz sto jednak







przyk ady kodu s skoncentrowane celowo na zademonstrowaniu okre lonegopoj cia albo funkcji interfejsu programowania aplikacji (API) w najprostszy mo -liwy sposób, bez zwracania uwagi na zasady dobrego projektowania. Pomimoto nadmiernie uproszczony kod przyk adów, w których zwykle wyst puje mnó-stwo getterów i setterów, jest kopiowany ka dego dnia bez zwracania zbytniejuwagi na projekt.

Istnieje jeszcze jeden, o wiele starszy wp yw. „Staro ytna” historia j zykaVisual Basic firmy Microsoft ma du o wspólnego z tym, z czym mamy dzi doczynienia. Nie twierdz , e Visual Basic by z ym j zykiem i zintegrowanymrodowiskiem programisty (IDE), poniewa zawsze by o to wysoce produktywnerodowisko i w pewnym sensie wp yn o na rozwój bran y. Oczywi cie niektórzy

deweloperzy by mo e unikali jego bezpo redniego oddzia ywania, ale osta-tecznie Visual Basic po rednio wywar wp yw na prawie ka dego deweloperaoprogramowania. Zwró my uwag na przebieg czasowy pokazany w tabeli 1.3.

Tabela 1.3. Przebieg czasowy od Bogatych Zachowa do Nies awnej Anemii

Lataosiemdziesi te

1991 1992 – 1995 1996 1997 1998 –

Wp ywprogramowaniaobiektowegodzi ki rozwojowij zykówSmalltalk i C ++

W a ciwo cii arkuszew a ciwo cij zyka VisualBasic

Wizualnenarz dziai rodowiskaIDE staj sipowszechne

OpublikowanooprogramowanieJava JDK 1.0

SpecyfikacjaJavaBean

Eksplozjanarz dzibazuj cychna refleksjachkorzystaj cychz w a ciwo cidla platformJava i .NET

Mówi o wp ywie, jaki wywar y na bran w a ciwo ci i arkusze w a ciwo ci,dost pne zarówno za po rednictwem getterów i setterów, jak i za po rednictwemprojektanta formularzy Visual Basica — narz dzia, dzi ki któremu zdoby y takwielk popularno . Wystarczy o umie ci kilka niestandardowych egzemplarzykontrolek na formularzu, wype ni ich arkusze w a ciwo ci i voilà! Powstawa aw pe ni dzia aj ca aplikacja Windows. To zajmowa o zaledwie kilka minut, a niekilka dni, jakie by y potrzebne do zaprogramowania podobnej aplikacji przy bez-po rednim wykorzystaniu API systemu Windows i j zyka C.

Ale co to wszystko ma wspólnego z Anemicznymi Modelami Dziedziny?Standard Java-Bean pocz tkowo opracowano po to, by pomóc w tworzeniu wizu-alnych narz dzi programowania dla Javy. Motywacj do jego powstania by oprzeniesienie mo liwo ci technologii Microsoft ActiveX na platform Javy. Tostworzy o nadziej na stworzenie rynku pe nego ró nego rodzaju kontrolek —podobnych do tych tworzonych w Visual Basicu — produkowanych przez ró -nych dostawców. Wkrótce do „wagonu” JavaBean wskoczy y prawie wszystkie







frameworki i biblioteki. W tej grupie znalaz y si wi ksza cz pakietu JavaSDK/JDK, jak równie takie biblioteki jak popularna biblioteka Hibernate.Z punktu widzenia zagadnie zwi zanych z DDD bibliotek Hibernate opraco-wano jako narz dzie utrwalania modeli dziedziny. Trend utrzymywa si do czasupojawienia si platformy .NET.

Co ciekawe, dowolny model dziedziny, który zosta utrwalony z wykorzy-staniem biblioteki Hibernate, w pocz tkowym okresie jej istnienia musia udo-st pnia publiczne gettery i settery zarówno dla ka dego prostego atrybutu, jaki dla z o onej asocjacji w ka dym obiekcie dziedziny. To oznacza o, e nawet je likto chcia zaprojektowa obiekt POJO (ang. Plain Old Java Object — dos . Prostystary obiekt Javy) z interfejsem obfituj cym w zachowania, to musia wewn trzneatrybuty udost pnia publicznie, tak by biblioteka Hibernate mog a utrwali ,a pó niej odtworzy obiekty dziedziny. Oczywi cie by y mo liwo ci ukryciapublicznego interfejsu JavaBean, ale ogólnie rzecz bior c, deweloperzy w wi kszo-ci nie zastanawiali si , dlaczego mieliby to robi (ani nawet tego nie rozumieli).

Czy korzystaj c z DDD, powinienem zastanawia si nad u ywaniemmaperów obiektowo-relacyjnych?Wcze niejsza krytyka biblioteki Hibernate wynika z perspektywy historycznej. Juod do d ugiego czasu biblioteka Hibernate wspiera wykorzystanie ukrytych getterówi setterów, a nawet bezpo redni dost p do pól. W kolejnych rozdzia ach poka , jakunikn anemii w tworzonych modelach w przypadku stosowania biblioteki Hiber-nate i innych mechanizmów utrwalania. Spokojna g owa!

Wi kszo , je eli nie wszystkie, frameworków webowych dzia a wy czniena bazie standardu JavaBean. Je eli obiekty Javy maj mie mo liwo wype -niania stron WWW, korzystniej by by o, aby zapewnia y lepsze wsparcie dlaspecyfikacji JavaBean. Je li formularze HTML maj wype nia obiekty Javy poprzes aniu na stron serwera, korzystniej by by o, eby obiekty formularzy Javyzapewnia y lepsze wsparcie dla specyfikacji JavaBean.

Niemal ka dy framework dost pny dzi na rynku wymaga u ywania publicz-nych w a ciwo ci prostych obiektów, promuj c je tym samym. Wi kszo dewe-loperów nie ma innego wyj cia. Musi ulec wp ywom wszystkich „anemicznych”klas wykorzystywanych w ich przedsi biorstwach. Trzeba si do tego przyzna .Czy nie dotyczy to tak e Ciebie, Czytelniku? W rezultacie mamy sytuacj , którnajlepiej opisuje etykieta anemia wsz dzie.

Jakie szkody wyrz dza anemia Twojemu modelowi?Za ó my wi c, e zgodzili my si z tym, i anemia jest faktem i jest dla nas irytu-j ca. Co anemia wsz dzie ma wspólnego z utrat pami ci? Co zazwyczaj widzimy,gdy czytamy kod klienta Anemicznego Modelu Dziedziny (na przyk ad oszuka -czej Us ugi Aplikacji [4, 14] à la Skrypt Transakcji)? Oto prosty przyk ad:







@Transactionalpublic void saveCustomer( String customerId, String customerFirstName, String customerLastName, String streetAddress1, String streetAddress2, String city, String stateOrProvince, String postalCode, String country, String homePhone, String mobilePhone, String primaryEmailAddress, String secondaryEmailAddress) {

Customer customer = customerDao.readCustomer(customerId);

if (customer == null) { customer = new Customer(); customer.setCustomerId(customerId); }

customer.setCustomerFirstName(customerFirstName); customer.setCustomerLastName(customerLastName); customer.setStreetAddress1(streetAddress1); customer.setStreetAddress2(streetAddress2); customer.setCity(city); customer.setStateOrProvince(stateOrProvince); customer.setPostalCode(postalCode); customer.setCountry(country); customer.setHomePhone(homePhone); customer.setMobilePhone(mobilePhone); customer.setPrimaryEmailAddress(primaryEmailAddress); customer.setSecondaryEmailAddress (secondaryEmailAddress);

customerDao.saveCustomer(customer);}

Celowo prosty przyk adCo prawda ten przyk ad nie pochodzi z bardzo interesuj cej dziedziny, ale pomagazbada daleki od idea u projekt i zdecydowa , jak go zrefaktoryzowa , tak by sta siznacznie lepszy. Powiedzmy jasno, e to wiczenie nie ma na celu doprowadzi nasdo lepszego sposobu zapisywania danych. Chodzi o tworzenie modelu oprogramowa-nia, które dodaje warto do Twojego biznesu, mimo e ten przyk ad mo e nie wyda-wa si warto ciowy.

Co ten kod w a ciwie robi? W istocie jest on do uniwersalny. Zapisuje obiektCustomer niezale nie od tego, czy jest on nowy, czy istnia wcze niej. Zapisuje obiektCustomer niezale nie od tego, czy zmieni o si nazwisko, czy te osoba przeprowa-dzi a si do nowego domu. Zapisuje obiekt Customer bez wzgl du na to, czy osobaotrzyma a nowy numer telefonu domowego, czy zrezygnowa a z us ug telekomu-nikacyjnych, oraz niezale nie od tego, czy po raz pierwszy otrzyma a telefonkomórkowy, czy mia y miejsce obie te sytuacje naraz. Zapisuje obiekt Customernawet wtedy, gdy osoba zacz a u ywa Gmaila zamiast Juno albo zmieni a praci teraz korzysta z s u bowego adresu e-mail. Wow! Co za niezwyk a metoda!







Czy rzeczywi cie? W a ciwie nie mamy adnych informacji na temat tego,w jakich sytuacjach biznesowych ta metoda saveCustomer() jest u ywana — przy-najmniej nie do ko ca. Dlaczego ta metoda zosta a w ogóle utworzona? Czyktokolwiek pami ta jej pierwotne przeznaczenie oraz wszystkie motywacje do jejzmieniania, by udzieli wsparcia dla szerokiego wachlarza celów biznesowych?Te wspomnienia z pewno ci zosta y utracone zaledwie kilka tygodni albo mie-si cy po tym, jak metod stworzono, a potem zmodyfikowano. Jest jeszcze gorzej.Trudno w to uwierzy ? Przyjrzyjmy si kolejnej wersji tej samej metody:

@Transactionalpublic void saveCustomer( String customerId, String customerFirstName, String customerLastName, String streetAddress1, String streetAddress2, String city, String stateOrProvince, String postalCode, String country, String homePhone, String mobilePhone, String primaryEmailAddress, String secondaryEmailAddress) {

Customer customer = customerDao.readCustomer(customerId);

if (customer == null) { customer = new Customer(); customer.setCustomerId(customerId); } if (customerFirstName != null) { customer.setCustomerFirstName(customerFirstName); } if (customerLastName != null) { customer.setCustomerLastName(customerLastName); } if (streetAddress1 != null) { customer.setStreetAddress1(streetAddress1); } if (streetAddress1 != null) { customer.setStreetAddress2(streetAddress2); } if (city != null) { customer.setCity(city); } if (stateOrProvince != null) { customer.setStateOrProvince(stateOrProvince); } if (postalCode != null) { customer.setPostalCode(postalCode); } if (country != null) { customer.setCountry(country); } if (homePhone != null) { customer.setHomePhone(homePhone); } if (mobilePhone != null) { customer.setMobilePhone(mobilePhone);







} if (primaryEmailAddress != null) { customer.setPrimaryEmailAddress(primaryEmailAddress); } if (secondaryEmailAddress != null) { customer.setSecondaryEmailAddress (secondaryEmailAddress); }

customerDao.saveCustomer(customer);}

Musz tutaj zaznaczy , e ten przyk ad nie jest taki z y, jak si wydaje. Cz -sto si zdarza, e kod mapowania danych ma do z o on form i zawierawewn trz sporo logiki biznesowej. Oszcz dzi em Ci, Czytelniku, w tym przyk a-dzie najgorszego, ale prawdopodobnie dostrzeg e to sam.

Teraz ka dy z parametrów innych ni customerId jest opcjonalny. Mo emywi c u y tej metody, by zapisa obiekt Customer w co najmniej kilkunastu sytu-acjach biznesowych! Ale czy to naprawd jest dobre? W jaki sposób mogliby myprzetestowa t metod , by zyska pewno , e w nieodpowiednich sytuacjachobiekt Customer nie zostanie zapisany?

Bez wchodzenia w zbyt wiele szczegó ów mo na powiedzie , e istniejeznacznie wi cej sposobów nieprawid owego dzia ania tej metody ni sposobówjej poprawnego dzia ania. By mo e istniej ograniczenia bazy danych, którezapobiegaj utrwalaniu zupe nie nieprawid owego stanu, ale w przypadku takiejpostaci, w jakiej kod wyst puje teraz, musieliby my zajrze do bazy danych, ebymie pewno . Prawie na pewno zajmie nam jaki czas znalezienie mentalnegoodwzorowania pomi dzy atrybutami Javy a nazwami kolumn. Kiedy ju spraw-dzimy t cz , mo emy si dowiedzie , e ogranicze bazy danych nie ma alboe s one niekompletne.

Mogliby my przyjrze si wielu klientom (nie licz c tych, które zosta y dodanepo zako czeniu tworzenia interfejsu u ytkownika w celu zarz dzania automa-tycznymi zdalnymi klientami) i porówna wersje kodu ród owego, aby uzyskajaki pogl d na temat tego, dlaczego kod zosta zaimplementowany w a nie takjak teraz. Podczas poszukiwania odpowiedzi dowiemy si , e nikt nie potrafiwyja ni , z jakiej przyczyny ta jedna metoda dzia a tak, jak dzia a; nikt nie potrafite powiedzie , ile istnieje prawid owych przypadków u ycia. Zrozumienie tegobez niczyjej pomocy mog oby zaj nawet kilka godzin albo dni.

Logika kowbojaAJ: Ten facet jest tak zdezorientowany, e nie wie, czy nosi

na plecach kartofle, czy te je dzi na rolkach w sta-dzie bawo ów.






W J AK I S P O S Ó B S T O S O W A DDD? 63

Eksperci dziedziny nie mog tutaj pomóc, poniewa by zrozumie kod, musie-liby by programistami. Nawet je li kilku ekspertów dziedziny wie o programo-waniu chocia tyle, aby przynajmniej potrafi przeczyta kod, to prawdopodobniepróbuj c wyja ni , co ten kod ma wspiera , b d tak samo zagubieni jak dewelo-per. Bior c pod uwag te wszystkie wzgl dy, zastanówmy si , czy o mielimy sizmieni ten kod, a je eli tak, to jak si do tego zabierzemy.

Istniej tutaj przynajmniej trzy powa ne problemy:

1. Interfejs metody saveCustomer() niezbyt dok adnie opisuje cel jej dzia ania.

2. Implementacja metody saveCustomer() wprowadza ukryt z o ono .

3. „Obiekt dziedziny” Customer w rzeczywisto ci wcale nie jest obiektem. Jesttylko nieinteligentnym kontenerem na dane.

Nazwijmy t sytuacj , która jest nie do pozazdroszczenia, utrat pami ciwywo an anemi . Taka sytuacja zdarza si bardzo cz sto podczas pracy nad pro-jektami, w których tworzony jest ten rodzaj niejawnego i ca kowicie subiektyw-nego „projektu” kodu.

Wstrzymaj si przez chwil !

W tym momencie niektórzy czytelnicy mogliby pomy le : „Nasze projekty nigdy niewykraczaj poza bia tablic . Rysujemy jak struktur , a kiedy osi gniemy poro-zumienie, mo emy swobodnie przej do implementacji. To przera aj ce”.

Je li tak pomy la e , spróbuj nie odró nia projektu od implementacji. Pami taj,e je eli stosujesz DDD, to projekt jest kodem, a kod jest projektem. Mówi c inaczej,

schematy rysowane na bia ej tablicy nie s projektem, a jedynie sposobem dyskuto-wania o wyzwaniach modelu.

Czytaj uwa nie. W dalszej cz ci tej ksi ki nauczysz si czerpa pomys y z rysun-ków na bia ej tablicy i wykorzystywa je w pracy.

W tym momencie czytelnik powinien umie dostrzega niebezpiecze stwazwi zane z u ywaniem z ego kodu i czu potrzeb tworzenia lepszego projektu.Dobra wiadomo jest taka, e mo esz odnie sukces w opracowywaniu jaw-nego, dok adnego projektu kodu.

W jaki sposób stosowa DDD?Spróbujmy odej na chwil od trudnych dyskusji na temat implementacji i opo-wiedzie o jednej z najpot niejszych w asno ci metod DDD — J zyku Wszech-obecnym. Jest to jeden z dwóch najwa niejszych filarów DDD. Drugim jest Kon-tekst Ograniczony (2). Jeden nie mo e istnie bez drugiego.







Poj cia w kontek cie

Na t chwil pomy l o Kontek cie Ograniczonym jak o poj ciowej granicy wokóca ej aplikacji albo jak o sko czonym systemie. Celem istnienia tej granicy jest pod-kre lenie tego, e ka de u ycie okre lonego poj cia, frazy lub zdania WszechobecnegoJ zyka wewn trz tej granicy ma okre lone znaczenie w kontek cie. Dowolne u yciepoj cia na zewn trz tej granicy mog oby mie , i prawdopodobnie mia oby, ca kowicieinne znaczenie. Konteksty Ograniczone zosta y szczegó owo opisane w rozdziale 2.

J zyk WszechobecnyJ zyk Wszechobecny jest wspólnym j zykiem, którym pos uguje si zespó . Pos u-guj si nim zarówno eksperci dziedziny, jak i deweloperzy. W istocie pos ugujsi nim wszyscy cz onkowie zespo u projektowego. Niezale nie od tego, jakfunkcj pe nisz w zespole, ze wzgl du na to, e w nim jeste , pos ugujesz si J zy-kiem Wszechobecnym projektu.

Zatem uwa asz ju , e wiesz, czym jest J zyk Wszechobecny?

Oczywi cie, jest to j zyk biznesu.

Otó nie.

Z pewno ci musi to by przyj ta terminologia bran owa.

Nie s dz .

Wyra nie wygl da to na argon u ywany przez ekspertów dziedziny.

Przepraszam, ale nie.

J zyk Wszechobecny jest wspó dzielonym j zykiem rozwijanym przez zespó — gruptworzon zarówno przez ekspertów dziedziny, jak i deweloperów oprogramowania.

To jest to! Teraz uchwycili my sedno!

Naturalnie eksperci dziedziny maj du y wp yw na J zyk, poniewa najlepiej znaj tcz biznesu. Maj na niego wp yw tak e standardy obowi zuj ce w bran y. Jednak eJ zyk jest w wi kszym stopniu skoncentrowany na tym, wed ug jakich regu dzia asam biznes. Cz sto równie zdarza si , e dwóch lub wi cej ekspertów dziedziny niezgadza si w kwestii poj i terminów, z którymi pracuj . S one zazwyczaj le rozu-miane ze wzgl du na to, e wcze niej eksperci niewystarczaj co dok adnie przemy-leli ka dy z przypadków. Zatem podczas gdy eksperci dziedziny i deweloperzy pra-

cuj razem w celu opracowania modelu dziedziny, prowadz dyskusje zmierzaj cezarówno do kompromisu, jak i konsensusu, by uzyska najlepszy J zyk dla projektu,zespó nigdy nie idzie na kompromis w zakresie jako ci J zyka. Przedmiotem kom-promisu s jedynie najlepsze poj cia, terminy i znaczenia. Pocz tkowa zgoda nie ozna-cza jednak zgody ostatecznej. J zyk rozwija si i zmienia w czasie. Osi gane s ma ei du e prze omy — zupe nie tak, jak w ywym j zyku.

Nie chodzi g ównie o to, aby deweloperzy „byli po tej samej stronie” co eks-perci dziedziny. J zyk nie jest wy cznie podzbiorem biznesowego argonu, któ-rego deweloperzy maj obowi zek u ywa . To jest prawdziwy J zyk, tworzony






W J AK I S P O S Ó B S T O S O W A DDD? 65

przez ca y zespó : ekspertów dziedziny, deweloperów, analityków biznesowych —wszystkich bior cych udzia w budowaniu systemu. Punktem wyj cia dla J zykamog by terminy, które s naturalnym argonem ekspertów dziedziny. J zyknie ogranicza si jednak wy cznie do nich, poniewa sam J zyk z czasem musi sirozwija . Wystarczy powiedzie , e kiedy eksperci dziedziny s zaanga owaniw tworzenie J zyka, cz sto nie zgadzaj si do pewnego stopnia w kwestii ter-minów i znacze , o których s dzono, e s ju powszechnie przyj te.

W tabeli 1.4 zaprezentowano model w kodzie „stosowania szczepionekgrypy”. Kod jest zapisany w J zyku, którym zespó powinien si otwarcie pos u-giwa . Gdy zespó omawia ten aspekt modelu, dos ownie s wypowiadane takiefrazy jak „Piel gniarki podaj pacjentom szczepionki grypy w standardowychdawkach”.

Tabela 1.4. Analiza najlepszego modelu dla biznesu

Które okre lenie jest lepsze dla biznesu?

Chocia zdania drugie i trzecie s podobne, to zastanówmy si , jak powinien byzaprojektowany kod.

Mo liwe punkty widzenia Wynikowy kod

„Kogo to obchodzi? Po prostu zakodujmyto jako ”.Hm, podej cie dalekie od prawid owego.

pacjent.ustawTypSzczepionki(TypySzczepionek.TYP_GRYPA);

pacjent.ustawDawke(dawka);pacjent.ustawPielegniarke(pielegniarka);

„Podajemy pacjentom szczepionki grypy”.Lepiej, ale nie uwzgl dniamy wa nych poj .

pacjent.podajSzczepionkeGrypy();

„Piel gniarka podaje pacjentom szczepionkigrypy w standardowych dawkach”.Wydaje si , e to najlepszy sposób— przynajmniej dopóki nie dowiemy si wi cej.

Szczepionka szczepionka =szczepionki.grypaStandardowaDawkaDorosli();

pielegniarka.podajeSzczepionkeGrypy(pacjent, szczepionka);

Podczas ewolucji J zyka b d uwidacznia y si drobne rozbie no ci pomi -dzy rozumieniem poj w formie, w jakiej istniej one w umys ach ekspertów,a tym, co z tego ewoluuje. Wszystko to jest cz ci naturalnego post pu rozwojujak najlepszego J zyka, który przez d ugi czas b dzie wywiera istotny wp ywna bran . Rozwój odbywa si przez otwart dyskusj , analiz istniej cych doku-mentów, „plemienn ” wiedz biznesow , która ostatecznie si tworzy, a tak ew wyniku odwo ywania si do standardów, s owników i tezaurusów. Trzeba rów-nie pami ta o sformu owaniach, w których pewne s owa i frazy nie pasuj dokontekstu biznesowego tak dobrze, jak pocz tkowo s dzili my; u wiadamiamysobie wtedy, e inne pasuj du o lepiej.







Zastanówmy si nad tym, w jaki sposób tworzy si ten niezwykle wa ny J zykWszechobecny. Poni ej podano kilka sprawdzonych metod. Pami tajmy, e eks-perymentowanie prowadzi do post pów.

Stwórz rysunki dziedziny fizycznej i poj ciowej i oznacz je etykietami opisuj -cymi nazwy i akcje. Te rysunki s g ównie nieformalne, ale mog zawierapewne aspekty formalnego modelowania oprogramowania. Nawet je li zespóstosuje pewne elementy formalnego modelowania z wykorzystaniem j zykaUML (ang. Unified Modeling Language), to staramy si unika formalnegostylu, aby nie ogranicza dyskusji i nie usztywni kreatywno ci szukanegoJ zyka w ostatecznej formie.

Utwórz glosariusz poj z prostymi definicjami. Wymie poj cia alternatywne,w cznie z tymi, które s obiecuj ce, oraz tymi, które si nie sprawdzi y.Zapisz informacj o tym, jakie by y powody niepowodzenia. Podczas do -czania definicji w gruncie rzeczy opracowujemy dla J zyka frazy wielokrotnegou ytku, poniewa jeste my zmuszeni do pisania z wykorzystaniem J zykadziedziny.

Je eli nie podoba Ci si pomys glosariusza, pos u si jakim rodzajem doku-mentacji, która zawiera nieformalne schematy wa nych poj oprogramowa-nia. Tak jak powiedzia em wcze niej, celem jest znalezienie dodatkowych poji fraz J zyka.

Poniewa glosariusz lub inne pisane dokumenty mog y by utworzone przezjednego albo kilku cz onków zespo u, udost pnij je pozosta ym cz onkomzespo u w celu wyra enia opinii. Nie zawsze musisz si zgadza ze wszyst-kimi podanymi terminami. Nale y zatem zachowa elastyczno i gotowodo redakcji.

S to pewne idealne pierwsze kroki zmierzaj ce do stworzenia J zyka Wszech-obecnego, które pasuj do konkretnej dziedziny. Jednak e absolutnie nie jest tomodel, który rozwijamy. Jest to tylko pocz tkowa posta J zyka Wszechobec-nego, która wkrótce zostanie wyra ona w kodzie ród owym Twojego systemu.Mówimy w Javie, C#, Scali albo jakim innym wybranym j zyku programowa-nia. Te rysunki i dokumenty nie uwzgl dniaj równie tego, e J zyk Wszech-obecny b dzie si nadal rozwija i przekszta ca . Artefakty, które pierwotnieprowadzi y nas po inspiruj cej cie ce zmierzaj cej do rozwijania przydatnegoJ zyka Wszechobecnego dopasowanego do okre lonej dziedziny specjalistycznej,z czasem stan si przestarza e. W a nie dlatego to mowa zespo u i model w kodzies najtrwalszym i jedynym gwarantowanym opisem J zyka Wszechobecnego.

Poniewa mowa zespo u i model w kodzie s trwa ym wyra eniem J zykaWszechobecnego, nale y przygotowa si na wyeliminowanie rysunków, glosa-riuszy i innej dokumentacji. Trudno by oby utrzyma t dokumentacj w zgodzie






W J AK I S P O S Ó B S T O S O WA DDD? 67

z mówionym J zykiem Wszechobecnym i kodem ród owym, które s szybkousprawniane. Nie jest to wymaganie zwi zane ze stosowaniem DDD, ale roz-wi zanie pragmatyczne, gdy utrzymywanie synchronizacji ca ej dokumentacjiz systemem staje si niepraktyczne.

Dysponuj c t wiedz , mo emy zmieni projekt przyk adu saveCustomer().Zastanówmy si , jak doprowadzi do tego, aby klasa Customer odzwierciedla awszystkie mo liwe cele biznesowe, które powinna wspiera .

public interface Customer { public void changePersonalName( String firstName, String lastName); public void postalAddress(PostalAddress postalAddress); public void relocateTo(PostalAddress changedPostalAddress); public void changeHomeTelephone(Telephone telephone); public void disconnectHomeTelephone(); public void changeMobileTelephone(Telephone telephone); public void disconnectMobileTelephone(); public void primaryEmailAddress(EmailAddress emailAddress); public void secondaryEmailAddress(EmailAddress emailAddress);}

Mo na by spiera si , e to nie jest najlepszy model dla klasy Customer, alepodczas stosowania metod DDD kwestionowanie projektu jest oczekiwane.Zespó mo e swobodnie dyskutowa na temat tego, co jest najlepszym modelem,i przyj ustalenia dopiero po odkryciu i uzgodnieniu J zyka Wszechobecnego.Interfejs zaprezentowany powy ej jawnie odzwierciedla ró ne biznesowe cele,które powinna wspiera klasa Customer pomimo wielu ulepsze J zyka mo liwychdo wprowadzenia w przysz o ci.

Trzeba równie wzi pod uwag , e wzorzec Us uga Aplikacji tak e by byrefaktoryzowany tak, by odzwierciedla wyra nie cele biznesowe. Ka da metodaUs ugi Aplikacji by aby modyfikowana w celu obs ugi pojedynczego przypadkuu ycia albo historyjki u ytkownika:

@Transactionalpublic void changeCustomerPersonalName( String customerId, String customerFirstName, String customerLastName) {

Customer customer = customerRepository.customerOfId(customerId);

if (customer == null) { throw new IllegalStateException("Customer does not exist."); }

customer.changePersonalName(customerFirstName, customerLastName);}







Pokazana metoda ró ni si od oryginalnego przyk adu, w którym wykorzy-stano pojedyncz metod do obs ugi wielu ró nych przypadków u ycia lub histo-ryjek u ytkownika. W nowym przyk adzie ograniczyli my pojedyncz metodUs ugi Aplikacji wy cznie do zmiany nazwiska klienta. Metoda nie robi nicwi cej. Zatem kiedy decydujemy si na zastosowanie DDD, naszym zadaniemjest odpowiednie udoskonalanie Us ug Aplikacji. To sugeruje, e interfejs u yt-kownika odzwierciedla w szy zakres celu u ytkownika ni ten, który zostapierwotnie wyznaczony. Jednak teraz ta okre lona metoda Us ugi Aplikacji niewymaga od klienta podawania dziesi ciu warto ci null za parametrami opisuj -cymi imi i nazwisko.

Czy ten nowy styl projektu u atwia zadanie naszemu umys owi? Mo emyczyta kod i bez trudu go rozumiemy. Mo emy te go przetestowa , by potwier-dzi , e robi dok adnie to, co powinien, oraz e nie robi niczego, czego robi niepowinien.

W ten sposób J zyk Wszechobecny staje si zespo owym wzorcem pozwa-laj cym uchwyci poj cia i terminy okre lonej g ównej dziedziny biznesowejw samym modelu oprogramowania. Ten model oprogramowania obejmujerzeczowniki, przymiotniki, czasowniki oraz bogatsze wyra enia stworzone w spo-sób formalny i u ywane przez zespó . Zarówno oprogramowanie, jak i testyweryfikuj ce zgodno modelu z regu ami dziedziny s wyra one w J zyku, któ-rym pos uguje si zespó .

Wszechobecny, ale nie uniwersalnyPrzyda oby si dodatkowe obja nienie dotycz ce zasi gu J zyka Wszechobecnego.Jest kilka podstawowych poj , o których powinni my pami ta :

„Wszechobecny” oznacza „dominuj cy” albo „obecny wsz dzie”, poniewaJ zykiem mówi cz onkowie zespo u i wyra a go model dziedziny, który zespórozwija.

U ycie s owa wszechobecny nie jest prób zaznaczenia, e chodzi o rodzajuniwersalnego j zyka dziedziny obowi zuj cego w ca ym przedsi biorstwielub na ca ym wiecie.

Jeden J zyk Wszechobecny obowi zuje w jednym Kontek cie Ograniczonym.

Konteksty Ograniczone s stosunkowo ma e — mniejsze ni mo na by tosobie pocz tkowo wyobrazi . Kontekst Ograniczony jest wystarczaj co du ytylko do tego, aby uchwyci kompletny J zyk Wszechobecny odizolowanejdziedziny biznesowej, i ani troch wi kszy.

J zyk jest wszechobecny tylko wewn trz zespo u, który pracuje nad projektemrozwijaj cym odizolowany Kontekst Ograniczony.






WA RTO BI Z N ES O WA U Y W ANI A T E CH N I K DDD 69

W projekcie, w którym jest rozwijany pojedynczy Kontekst Ograniczony,zawsze istnieje co najmniej jeden dodatkowy odizolowany Kontekst Ograni-czony, z którym podstawowy kontekst si integruje, u ywaj c Map Kontek-stu (3). Ka dy z wielu Kontekstów Ograniczonych integruj cych si ze sob maswój w asny J zyk Wszechobecny, chocia mog istnie terminy, które cz -ciowo si pokrywaj .

Próba zastosowania jednego J zyka Wszechobecnego w ca ym przedsi bior-stwie albo, jeszcze gorzej, J zyka uniwersalnego dla wielu przedsi biorstwzako czy si niepowodzeniem.

Gdy zaczynasz nowy projekt i masz zamiar prawid owo stosowa metodykDDD, zidentyfikuj odizolowany Kontekst Ograniczony, który b dzie rozwijany.To wyznacza wyra n granic wokó Twojego modelu dziedziny. Nale y oma-wia , przeprowadza badania, tworzy poj cia, rozwija i mówi J zykiemWszechobecnym odizolowanego modelu dziedziny w ramach jawnie okre lonegoKontekstu Ograniczonego. Nale y odrzuca wszystkie poj cia, które nie s cz ciuzgodnionego J zyka Wszechobecnego Twojego odizolowanego Kontekstu.

Warto biznesowa u ywania technik DDDJe eli do wiadczenie czytelnika w jakim stopniu przypomina moje, to z pew-no ci jest mu wiadome, e deweloperzy oprogramowania nie s w stanie u y-wa wszystkich technologii i technik tylko dlatego, e wydaj si one wietnealbo intryguj ce. Musimy uzasadni wszystko, co robimy. My l , e nie zawszetak by o, ale dobrze, e taka zasada obowi zuje teraz. Uwa am, e najlepszymuzasadnieniem stosowania dowolnej technologii lub techniki jest dostarczaniewarto ci dla biznesu. Je eli jeste my w stanie ustali prawdziw , namacaln war-to biznesow , to z jakich powodów biznes móg by odrzuci to, co polecamy?

Przypadek biznesowy jest wzmocniony zw aszcza wtedy, gdy mo emy zade-monstrowa , e w porównaniu z innymi mo liwo ciami warto ci biznesowewynikaj ce z zastosowania polecanego przez nas podej cia s wi ksze.

Czy warto biznesowa nie jest najwa niejsza?Z pewno ci jest. By mo e wcze niej powinienem zastosowa podtytu „Wartobiznesowa u ywania DDD”. Ale robi to teraz. Ten podtytu móg by w a ciwiebrzmie : „Jak sprzedawa DDD szefowi?”. Do czasu, kiedy nie b dziesz przekonany,e istnieje realna szansa implementacji DDD w Twojej firmie, ta ksi ka jest tylko

hipotetyczna. Nie chc , aby lektura tej publikacji by a dla czytelnika wy cznie wi-czeniem teoretycznym. Proponuj , by w trakcie czytania tej ksi ki porównywaopisane w niej sytuacje do konkretnej rzeczywisto ci swojego przedsi biorstwa. Wtedymo na atwiej zaobserwowa realne korzy ci, jakie mo e osi gn firma. Zach camzatem do kontynuowania lektury.







Rozwa my bardzo realistyczn biznesow warto zastosowania DDD. Wartootwarcie podzieli si tymi spostrze eniami z kierownictwem, ekspertami dzie-dziny i technicznymi cz onkami zespo u. Poni ej sumarycznie przedstawi emwarto i korzy ci, które mo na osi gn . W dalszej cz ci opisa em je bardziejszczegó owo. Zaczn od korzy ci o mniej technicznym charakterze:

1. Organizacja zyskuje przydatny model swojej dziedziny.

2. Powstaje udoskonalona i dok adna definicja biznesu.

3. Eksperci dziedziny przyczyniaj si do tworzenia projektu oprogramowania.

4. U ytkownicy zyskuj system wygodniejszy do u ywania.

5. Wokó modeli tworzone s czytelne granice.

6. Architektura przedsi biorstwa jest lepiej zorganizowana.

7. Stosowane jest zwinne, iteracyjne, ci g e modelowanie.

8. Wykorzystywane s nowe narz dzia, zarówno na poziomie strategicznym, jaki taktycznym.

1. Organizacja zyskuje przydatny model swojej dziedzinyMetodologia DDD k adzie nacisk na zainwestowanie wysi ków w dzia ania, któremaj najwi ksze znaczenie dla biznesu. Nie staramy si stosowa nadmiernegomodelowania. Skupiamy si na Dziedzinie G ównej. Istniej równie inne modele,które wspieraj Dziedzin G ówn . One tak e s wa ne. Jednak modele pomoc-nicze nie zawsze otrzymuj taki priorytet i nie zawsze po wi ca si im tyle wysi kuco Dziedzinie G ównej.

Dzi ki temu, e koncentrujemy si na tym, co odró nia nasz biznes od wszyst-kich innych, mo emy dobrze zrozumie nasz misj i poznajemy parametry,które powinni my ledzi . Dostarczymy dok adnie to, co jest potrzebne do tego,by osi gn konkurencyjn przewag .

2. Powstaje udoskonalona i dok adna definicja biznesuDzi ki DDD biznes i jego misja mog zosta zrozumiane lepiej ni kiedykolwiekwcze niej. S ysza em kiedy zdanie, zgodnie z którym J zyk Wszechobecny opra-cowany dla Dziedziny G ównej biznesu znalaz swoj drog do materia ówmarketingowych. Z pewno ci nale a oby go w czy do dokumentów dotycz -cych wizji i misji.

W miar up ywu czasu i udoskonalania modelu w biznesie rozwija si g -bokie zrozumienie problematyki biznesu — mo e to s u y za narz dzie analizy.Eksperci dziedziny ujawniaj szczegó y, które s kszta towane przez technicz-






WA RTO BI Z N ES O WA U Y W ANI A T E CH N I K DDD 71

nych partnerów w zespole. Te szczegó y pomagaj w analizie warto ci bie cegokierunku oraz kierunków w przysz o ci — zarówno na poziomie strategicznym,jak i taktycznym.

3. Eksperci dziedziny przyczyniaj si do tworzeniaprojektu oprogramowania

Zyskanie g bszego zrozumienia sedna biznesu przez cz onków organizacji two-rzy warto biznesow . Eksperci dziedziny nie zawsze zgadzaj si w kwestiipoj i terminologii. Czasami ró nicom sprzyjaj ró ne do wiadczenia z zewn trz,ukszta towane zanim eksperci do czyli do organizacji. Innym razem ró nicewynikaj z rozbie nych cie ek obranych przez ka dego eksperta w ramach tejsamej organizacji. Pomimo ró nic eksperci dziedziny zaanga owani w procesDDD osi gaj konsensus. To wzmacnia si zespo u i organizacj jako ca o .

Deweloperzy zyskuj teraz wspólny J zyk w ramach jednolitego zespo u —razem z ekspertami dziedziny. Dodatkowe korzy ci osi gaj z transferu wiedzyod ekspertów dziedziny, z którymi pracuj . atwiejsze jest równie szkoleniei przekazywanie wiedzy, co jest istotne ze wzgl du na to, e deweloperzy cz stoprzychodz i odchodz — albo do nowej Dziedziny G ównej, albo w ogóle opusz-czaj organizacj . Szanse na rozwój „wiedzy plemiennej”, kiedy tylko nieliczniwybra cy rozumiej model, s mniejsze. Eksperci, pozostali deweloperzy oraznowi cz onkowie zespo u kontynuuj dzielenie si wspóln wiedz , dost pndla wszystkich osób w organizacji, które jej potrzebuj . Ta korzy jest mo liwado osi gni cia ze wzgl du na wyra ny cel — zachowanie J zyka dziedziny.

4. U ytkownicy zyskuj system wygodniejszy do u ywaniaCz sto mo na poprawi wygod korzystania u ytkowników z systemu dzi kilepszemu odzwierciedleniu modelu dziedziny. Projektowanie DDD ma formalnie„wrodzon ” cech wywierania wp ywu na sposób pos ugiwania si oprogramo-waniem przez u ytkowników.

Gdy oprogramowanie pozostawia swoim u ytkownikom zbyt du o do rozu-mienia, powstaje konieczno szkolenia u ytkowników w celu uzyskania zdol-no ci podejmowania wi kszo ci decyzji. W gruncie rzeczy u ytkownicy przenoszzrozumienie tematu ze swoich umys ów na dane wprowadzane w formularzach.Dane te s nast pnie sk adowane w magazynie danych. Je eli u ytkownicy nierozumiej dok adnie, co jest potrzebne, wyniki s nieprawid owe. To cz sto pro-wadzi do zgadywanki, która ko czy si obni on produktywno ci , trwaj c doczasu, a u ytkownicy zrozumiej oprogramowanie.

Gdy wra enia u ytkownika zostan zaprojektowane tak, by by y zgodnez modelem stworzonym przez ekspertów dziedziny, u ytkownicy mog wyci gapoprawne wnioski. Oprogramowanie w istocie szkoli u ytkowników, co zmniejsza







koszty szkolenia dla biznesu. Szybsza droga do produktywno ci z mniejsz liczbszkole — to jest warto biznesowa.

W kolejnych punktach przejdziemy do bardziej technicznych korzy ci dlabiznesu.

5. Wokó modeli tworzone s czytelne graniceZespó techniczny w mniejszym stopniu zajmuje si dzia aniami, które mogwydawa si im u yteczne z punktu widzenia algorytmów i oprogramowania,poniewa musi sprosta oczekiwaniom w postaci korzy ci dla biznesu. Czystokierunku pozwala si skupi na sile rozwi zania — skierowa wysi ek tam, gdziema on najwi ksze znaczenie. Osi gni cie tego celu jest bardzo ci le powi zaneze zrozumieniem Kontekstu Ograniczonego projektu.

6. Architektura przedsi biorstwa jest lepiej zorganizowanaGdy Konteksty Ograniczone s dobrze rozumiane i uwa nie podzielone, wszyst-kie zespo y w przedsi biorstwie zaczynaj dok adnie rozumie , gdzie i dlaczegos potrzebne integracje. Zarówno granice, jak i relacje pomi dzy nimi s jasnowydzielone. Zespo y, które stosuj przecinaj ce si modele poprzez zale no cikorzystania, u ywaj Map Kontekstu w celu ustalenia formalnych relacji i spo-sobów integracji. W rezultacie mo e to doprowadzi do bardzo gruntownegozrozumienia ca ej architektury przedsi biorstwa.

7. Stosowane jest zwinne, iteracyjne, ci g e modelowanieS owo projektowanie mo e wywo ywa negatywne skojarzenia w umys ach przed-stawicieli kierownictwa. DDD nie jest jednak trudnym, mocno celebrowanymprocesem projektowania i rozwoju. DDD nie polega na rysowaniu wykresów.Polega na uwa nym dostrajaniu modelu my lenia ekspertów dziedziny i prze-kszta caniu go do postaci modelu przydatnego dla biznesu. Nie chodzi o stworze-nie modelu z rzeczywistego wiata, tak jak w modelach, które próbuj na lado-wa rzeczywisto .

Wysi ki zespo u s podejmowane zgodnie ze zwinnym podej ciem do pro-jektowania — bazuj cym na procesie iteracyjnym i przyrostowym. W projekcieDDD mo e by skutecznie zastosowany dowolny proces, którym zespó sprawniesi pos uguje. Stworzonym modelem jest dzia aj ce oprogramowanie. Jest onoci gle udoskonalane — tak d ugo, a biznes przestanie go potrzebowa .






WY ZW A NI A Z WI Z A N E Z E S TO S O W A N I E M DDD 73

8. Wykorzystywane s nowe narz dzia,zarówno na poziomie strategicznym, jak i taktycznym

Kontekst Ograniczony wyznacza zespo owi granic modelu, w obr bie którejmo na utworzy rozwi zanie okre lonej biznesowej dziedziny problemu.Wewn trz pojedynczego Kontekstu Ograniczonego wykorzystywany jest J zykWszechobecny sformu owany przez zespó . Pos uguj si nim cz onkowie zespo ui jest on obecny w modelu oprogramowania. Zasadniczo odmienne zespo y(czasami ka dy odpowiedzialny jest za inny Kontekst Ograniczony) u ywaj MapKontekstu w celu strategicznej segregacji Kontekstów Ograniczonych i zrozu-mienia ich integracji. W obr bie pojedynczej granicy modelowania zespó mo ewykorzysta dowoln liczb przydatnych narz dzi modelowania: Agregaty (10),Encje (5), Obiekty Warto ci (6), Us ugi (7), Zdarzenia Dziedziny (8) i inne.

Wyzwania zwi zane ze stosowaniem DDDPodczas wdra ania DDD napotykamy rozmaite wyzwania. Jest to typowe dlaka dego, komu uda o si skutecznie wdro y to rozwi zanie. Jakie s popularnewyzwania i jak mo na usprawiedliwi u ycie DDD, gdy przed nimi staniemy?Poni ej omówi najpopularniejsze z nich:

koszty czasu i pracy, jakie trzeba ponie w zwi zku z tworzeniem J zykaWszechobecnego;

zaanga owanie ekspertów dziedziny w pocz tkowej fazie projektu i przez ca yczas jego trwania;

zmiana sposobu my lenia deweloperów o rozwi zaniach w ich dziedzinie.

Jednym z najwi kszych wyzwa w u ywaniu DDD s koszty czasu i pracy,jakie trzeba ponie podczas my lenia o dziedzinie biznesu, badaniu poj i termi-nologii oraz rozmowach z ekspertami dziedziny w celu odkrywania, ujednolica-nia i ulepszania J zyka Wszechobecnego. Nie mo na od razu przej do kodowaniaw technopaplaninie. Je eli chcemy zastosowa DDD w sposób kompletny, takaby przynios o to najwi ksz warto dla biznesu, trzeba w o y w to wi cej energiiumys owej i wysi ku, co wymaga wi cej czasu. Na wszystko jest potrzebny czas.

Wyzwaniem mo e by tak e utrzymanie koniecznego zaanga owania eks-pertów dziedziny. Niezale nie od tego, jak trudno to osi gn , jest to konieczne.Je eli w projekt nie zaanga uje si co najmniej jeden prawdziwy ekspert, nieuda nam si odkry g bokiej wiedzy z zakresu dziedziny. Gdy uda nam sizdoby zaanga owanie ekspertów dziedziny, mo emy skoncentrowa si na dewe-loperach. Deweloperzy musz ze sob rozmawia i uwa nie s ucha prawdziwychekspertów, modeluj c j zyk mówiony na oprogramowanie, które odzwierciedlaich mentalny model dziedziny.







Je eli dziedzina, w której pracujemy, jest naprawd specyficzna dla naszegobiznesu, to eksperci dziedziny maj najbardziej kluczow wiedz zamkni tw swoich umys ach. Trzeba j stamt d wyci gn . Uczestniczy em w projektach,w przypadku których spotkania z ekspertami dziedziny by y bardzo utrudnione.Czasami eksperci du o podró owali. Bywa o, e pomi dzy jednogodzinnymispotkaniami up ywa o kilka tygodni. W ma ych przedsi biorstwach ekspertemdziedziny mo e by dyrektor zarz dzaj cy albo jeden z wiceprezesów. Osoby temaj na g owie wiele innych spraw, które mog im si wydawa wa niejsze.

Logika kowbojaAJ: Je eli nie potrafisz schwyta du ego bawo a, b dziesz

musia g odowa .

Zdobycie zaanga owania ekspertów dziedziny mo e wymaga kreatywno ci…

Jak zaanga owa ekspertów dziedzinyw projektPrzerwa na kaw . U ywaj takiego J zyka Wszech-obecnego:

„Cze , Zosiu, przynios em ci du y kubek lekkiej, eks-tragor cej, mieni cej si latte z piank . Czy znajdzieszkilka minut, by porozmawia …?”.

Naucz si u ywa J zyka Wszechobecnego kierow-nictwa poziomu C: „…zyski, …, …dochody, …prze-waga konkurencyjna, …dominacja rynku”. Naprawdwarto.

Notatki na serwetce.

Wi kszo deweloperów musi zmieni sposób my lenia, by móc skuteczniezastosowa DDD. My, deweloperzy, my limy w kategoriach technicznych. Tech-niczne rozwi zania przychodz nam atwo. Nie chc powiedzie , e my lenie tech-nicznie jest czym z ym. Chodzi o to, e czasami my lenie w sposób mniej technicznyjest lepsze. Je eli przez ca e lata mieli my w zwyczaju praktykowa rozwijanieoprogramowania wy cznie w sposób techniczny, to by mo e nadszed odpo-wiedni czas, aby zastanowi si nad nowym sposobem my lenia. Rozwijanie J zykaWszechobecnego swojej dziedziny jest najlepszym punktem wyj cia.







Logika kowbojaLB: Buty tego faceta s za ma e. Je eli nie znajdzie sobie

innej pary, zaczn bole go palce.

AJ: Tak jest. Je li nie b dziesz s ucha , b dziesz musiapoczu .

W przypadku stosowania DDD potrzebny jest inny poziom my lenia, wykra-czaj cy poza nazewnictwo poj . Gdy modelujemy dziedzin poprzez oprogra-mowanie, musimy dok adnie zastanowi si nad tym, co robi poszczególneobiekty modelu. Modelowanie sprowadza si do projektowania zachowaniaobiektów. To prawda. Chcemy, aby zachowania by y w a ciwie nazwane, takby oddawa y istot J zyka Wszechobecnego. Ale trzeba tak e wzi pod uwagto, co robi obiekt, w kontek cie okre lonego zachowania. Ten wysi ek wykraczapoza tworzenie atrybutów klasy i wystawianie publicznych getterów i setterówna u ytek klientów modelu.

Przyjrzyjmy si teraz bardziej interesuj cej dziedzinie — takiej, która stawiawi cej wyzwa w porównaniu z prost dziedzin omawian wcze niej. Celowopowtarzam moje poprzednie wskazówki, aby utrwali poj cia.

Zastanówmy si , co si stanie, je eli ograniczymy si do przygotowania pro-cedur dost pu do danych naszego modelu. Mówi c dok adniej, je li udost pnimysame procedury dost pu do danych obiektów modelu, w rezultacie uzyskamyjedynie model danych. Przyjrzyjmy si dwóm przyk adom zaprezentowanymponi ej i zastanówmy si , który z nich wymaga dok adniejszej analizy projek-towej oraz który przynosi wi ksz korzy dla klientów. Wymaganie dotyczymodelu Scrum. Polega na przypisaniu pozycji rejestru zada do wykonania dosprintu. Prawdopodobnie robisz to ca y czas, wi c jest to dla Ciebie do znajomadziedzina.

W pierwszym przyk adzie, tak jak powszechnie si to robi, wykorzystanometody dost pu do atrybutów:

public class BacklogItem extends Entity { private SprintId sprintId; private BacklogItemStatusType status; ... public void setSprintId(SprintId sprintId) { this.sprintId = sprintId; }

public void setStatus(BacklogItemStatusType status) { this.status = status; } ...}







A oto kod klienta tego modelu:

// klient przypisuje pozycj rejestru do sprintu// poprzez ustawienie atrybutów sprintId i status

backlogItem.setSprintId(sprintId);backlogItem.setStatus(BacklogItemStatusType.COMMITTED);

W drugim przyk adzie skorzystano z zachowania obiektu dziedziny, którewyra a J zyk Wszechobecny dziedziny:

public class BacklogItem extends Entity { private SprintId sprintId; private BacklogItemStatusType status; ...

public void commitTo(Sprint aSprint) { if (!this.isScheduledForRelease()) { throw new IllegalStateException( "Pozycja musi by zaplanowana do wydania, aby mo na j by o przypisa do sprintu".); }

if (this.isCommittedToSprint()) { if (!aSprint.sprintId().equals(this.sprintId())) { this.uncommitFromSprint(); } }

this.elevateStatusWith(BacklogItemStatus.COMMITTED);

this.setSprintId(aSprint.sprintId());

DomainEventPublisher .instance() .publish(new BacklogItemCommitted( this.tenant(), this.backlogItemId(), this.sprintId())); } ...}

Wydaje si , e klient tego wyra nego modelu st pa po bezpieczniejszym gruncie:

// klient przypisuje pozycj rejestru do sprintu,// przejawiaj c zachowanie specyficzne dla dziedziny

backlogItem.commitTo(sprint);

W pierwszym przyk adzie skorzystano z podej cia bardzo ukierunkowanegona dane. Obci enie zwi zane z poprawnym przypisaniem pozycji rejestru do







sprintu w ca o ci spoczywa na kliencie. Model, który w istocie nie jest modelemdziedziny, zupe nie w tym nie pomaga. Co si stanie, je eli klient przez pomy kzmieni tylko pole sprintId, a nie zmieni pola status lub post pi odwrotnie? Albo cosi stanie, je eli w przysz o ci zajdzie potrzeba ustawienia warto ci innego atrybutu?Trzeba b dzie przeanalizowa kod klienta, aby zaimplementowa prawid oweodwzorowanie warto ci danych na odpowiednie atrybuty obiektu BacklogItem.

Zastosowanie tego podej cia ujawnia równie kszta t obiektu BacklogItemi wyra nie skupia uwag na jego atrybutach danych, a nie na jego zachowaniach.Nawet je li przyj liby my, e metody setSprintId() i setStatus() s zachowa-niami, to te „zachowania” nie przynosz adnej prawdziwej biznesowej warto cidla dziedziny. Te „zachowania” nie wskazuj jawnie zamiarów scenariuszy, któreoprogramowanie dziedziny powinno modelowa — tzn. przypisywania pozycjirejestru do sprintu. Powoduj one kognitywne przeci enie, gdy deweloper klientapróbuje w my lach wybra te spo ród atrybutów obiektu BacklogItem, które swymagane do przypisania pozycji do sprintu. Takich atrybutów mo e by du o,poniewa jest to model ukierunkowany na dane.

Rozwa my teraz drugi przyk ad. Zamiast udost pniania klientom atrybutówdanych model udost pnia zachowanie, które jawnie i wyra nie wskazuje, eklient mo e przypisa pozycj rejestru do sprintu. Eksperci w tej konkretnej dzie-dzinie dyskutuj nast puj ce wymaganie modelu:

Ka d pozycj rejestru mo na przypisa do sprintu. Pozycj mo na przypisa dosprintu tylko wtedy, gdy zosta a zaplanowana do wydania. Je eli zosta a ju przy-pisana do innego sprintu, to przypisanie musi by wcze niej anulowane. Gdyprzypisanie zostanie zako czone, nale y powiadomi o tym zainteresowanych.

Zatem metoda z drugiego przyk adu oddaje J zyk Wszechobecny modeluw kontek cie — tzn. Kontek cie Ograniczonym, w którym wyizolowano typBacklogItem. Co wi cej, podczas analizy tego scenariusza odkryjemy, e pierwszerozwi zanie jest niekompletne i zawiera b dy.

W przypadku zastosowania drugiej implementacji klienci nie musz wiedzie ,co jest wymagane do realizacji przypisania — niezale nie od tego, czy jest tooperacja prosta, czy z o ona. W implementacji tej metody jest tylko tyle logiki, ilejest konieczne. Z atwo ci dodali my warunek zabezpieczaj cy przed przypisaniemdo sprintu pozycji rejestru, która jeszcze nie zosta a zaplanowana do wydania.Oczywi cie mo na tak e umie ci warunki wewn trz setterów w pierwszej imple-mentacji, ale settery b d odt d odpowiedzialne za zrozumienie pe nego kontekstustanu obiektu, a nie samych wymaga dotycz cych atrybutów sprintId i status.

Istnieje równie inna subtelna ró nica. Zwró my uwag , e je eli pozycjarejestru zosta a wcze niej przypisana do innego sprintu, to najpierw b dzie anulo-wane przypisanie jej aktualnego sprintu. To jest wa ny szczegó , bo kiedy nast pujeanulowanie przypisania pozycji rejestru ze sprintu, trzeba zg osi klientom Zdarze-nie Dziedziny:







Mo na anulowa przypisanie do sprintu ka dej pozycji rejestru. W przypadkuanulowania przypisania pozycji rejestru do sprintu nale y powiadomi zaintere-sowanych.

Opublikowanie powiadomienia o anulowaniu przypisania uzyskuje si „zadarmo” — poprzez u ycie zachowania dziedziny uncommitFrom(). MetodacommitTo() nie musi nawet wiedzie o tym, e inicjuje powiadomienie. Musi jedy-nie wiedzie , e przed przypisaniem pozycji rejestru do nowego sprintu trzebaanulowa przypisanie tej pozycji rejestru do dowolnych innych sprintów. Dodat-kowo w ramach zachowania dziedziny commitTo() nast puje powiadomienie zapomoc Zdarzenia zainteresowanych stron. Bez umieszczenia tego bogategozachowania w obr bie obiektu BacklogItem trzeba by by o publikowa Zdarzeniaz poziomu klientów. To z pewno ci spowodowa oby ujawnienie logiki dziedzinyz modelu. To nie jest dobre.

Wyra nie wida , e stworzenie obiektu BacklogItem zgodnego z drugim przy-k adem wymaga wi cej przemy le w porównaniu z pierwszym. Chocia wysi-ek intelektualny nie jest znacz co wi kszy, korzy ci s du e. Im wi cej uczymy

si projektowa w ten sposób, tym projektowanie staje si atwiejsze. Ostateczniena pewno trzeba w o y wi cej wysi ku intelektualnego i wi cej pracy, nasiliwspó prac i zgrywanie wysi ków zespo u, ale nie do tego stopnia, aby metodykaDDD sta a si z o onym procesem. Nowy sposób my lenia jest wart wk adanegow to wysi ku.

Zapiski na tablicy

U ywaj c konkretnej dziedziny, w której aktualnie pracujesz, wyszukaj popu-larne poj cia i akcje w modelu.

Zapisz poj cia na tablicy.

Nast pnie zapisz frazy, które powinny by u ywane przez zespó podczas roz-mów dotycz cych projektu.

Podyskutuj o nich z prawdziwym ekspertem dziedziny, by dowiedzie si , jakmo na je udoskonali (pami taj, eby przynie kaw ).

Uzasadnienie dla modelowania dziedzinyModelowanie taktyczne jest, ogólnie rzecz bior c, bardziej z o one od modelowa-nia strategicznego. Zatem je eli zamierzasz rozwija model dziedziny u ywaj cytaktycznych wzorców DDD (Agregaty, Us ugi, Obiekty Warto ci, Zdarzeniaitd.), b dziesz zmuszony do wykonania wi kszej pracy umys owej i poniesieniawi kszych nak adów finansowych. Je li tak jest, to w jaki sposób organizacja uza-sadnia taktyczne modelowanie dziedziny? Jakich kryteriów nale y u y , by zakwa-lifikowa okre lony projekt do dodatkowych inwestycji niezb dnych do prawi-d owego zastosowania DDD od góry do do u?







Wyobra sobie, e przewodzisz wyprawie po nieznanym terenie. Chcia bypozna okoliczne l dy i granice. Twój zespó studiuje mapy, by mo e nawetrysuje swoje w asne, i okre la swoje strategiczne podej cie. Masz zamiar przeana-lizowa elementy terenu i zastanowi si , jak mo na by ich u y , aby przynios ykorzy ekspedycji. Niezale nie od wysi ków wk adanych w planowanie niektóreaspekty takiego przedsi wzi cia b d naprawd trudne.

Je eli z Twojej strategii wynika, e musisz si wspi na pionowe zbocze ska y,to do takiej wspinaczki potrzebujesz odpowiednich narz dzi taktycznych i w a-ciwych posuni . Stoj c na dole i patrz c w gór , mo na zauwa y pewne sygna y

okre lonych wyzwa i niebezpiecznych obszarów. Pomimo to nie wszystkie szcze-gó y b d widoczne. Zobaczysz je dopiero wtedy, kiedy zaczniesz si wspina .By mo e b dziesz zmuszony do zainstalowania haków na g adkiej skale, aleprawdopodobne jest równie , e wystarcz kliny w ró nych rozmiarach, insta-lowane w naturalnych p kni ciach. Aby móc przypi si do tego zabezpiecze-nia, b dziesz potrzebowa zapi typu karabi czyk. Mo esz spróbowa obrajak najprostsz cie k , ale musisz dokona szczegó owych ustale — punkt popunkcie. Czasami mo e nawet wyst pi konieczno wycofania si i zmianytrasy, w zale no ci od tego, co „podyktuje” ska a. Wiele osób uwa a wspinaczkza niebezpieczny sport, jednak te osoby, które rzeczywi cie si wspinaj , mówi ,e to jest bezpieczniejsze ni jazda samochodem albo latanie samolotem. Wydaje

si oczywiste, e aby tak by o, prawdziwi alpini ci musz rozumie narz dziai techniki pozwalaj ce na w a ciw ocen ska y.

Je eli rozwijanie okre lonej Poddziedziny (2) wymaga takiej trudnej, a nawetniepewnej wspinaczki, to warto zastosowa taktyczne wzorce DDD. W inicja-tywie biznesowej, która pasuje do kryteriów Dziedziny G ównej, nie nale y zbytszybko rezygnowa z u ycia wzorców taktycznych. Dziedzina G ówna jest nie-znanym i skomplikowanym obszarem. Najlepsz ochron przed katastrofalnymupadkiem podczas „wspinaczki” zespó uzyskuje dzi ki zastosowaniu odpowied-niej taktyki.

Oto kilka praktycznych wskazówek. Zaczn od najbardziej ogólnych, a nast p-nie przejd do szczegó ów.

Je eli Kontekst Ograniczony jest rozwijany jako Dziedzina G ówna, to maznaczenie strategiczne dla sukcesu przedsi wzi cia. Podstawowy model nie jestdobrze rozumiany. Wymaga wielu eksperymentów i refaktoryzacji. Prawdo-podobnie zas uguje na d ugotrwa e po wi cenie i ci g e ulepszanie. Nie zawszemusi to by Dziedzina G ówna. Niemniej jednak, je eli Kontekst Ograni-czony jest z o ony, nowatorski i b dzie musia przetrwa przez d ugi czasw trakcie wprowadzania zmian, nale y rozwa y u ycie wzorców taktycznychjako inwestycji w przysz o Twojego biznesu. Zak adamy tutaj, e DziedzinaG ówna zas uguje na najlepsze zasoby deweloperów o wysokich kwalifikacjach.

Dziedzina, która mo e si sta Poddziedzin Generyczn (2) albo Poddzie-dzin Pomocnicz dla swoich konsumentów, mo e w gruncie rzeczy sta si







Dziedzin G ówn dla biznesu. Nie zawsze oceniamy dziedzin z punktuwidzenia jej ostatecznych konsumentów. Je eli rozwijasz Kontekst Ograni-czony jako g ówn inicjatyw biznesow , to jest to Twoja Dziedzina G ównaniezale nie od tego, jak postrzegaj j klienci spoza biznesu. Nale y si powa -nie zastanowi nad u yciem wzorców taktycznych.

Je li rozwijasz Poddziedzin Pomocnicz , która z ró nych powodów nie mo eby pozyskana z zewn trz jako Poddziedzina Generyczna, to istnieje mo li-wo , e zastosowanie wzorców taktycznych przyniesie korzy . W takimprzypadku warto przeanalizowa umiej tno ci zespo u i zastanowi si , czymodel jest nowy i nowatorski. Mo na go uzna za nowatorski, je eli dodajeokre lon warto biznesow i obejmuje wiedz specjalistyczn , a nie wtedy,gdy jest jedynie intryguj cy z technicznego punktu widzenia. Je li zespópotrafi w a ciwie zastosowa projekt taktyczny, a Poddziedzina Pomocniczajest nowatorska i b dzie musia a przetrwa przez wiele lat, to warto zainwesto-wa w oprogramowanie, wykorzystuj c projektowanie taktyczne. Jednak enie czyni to z tego modelu Dziedziny G ównej, poniewa z punktu widzeniabiznesu jest do jedynie Poddziedzina Pomocnicza.

Powy sze wytyczne mog troch ogranicza — zw aszcza je li w Twojejfirmie jest zatrudnionych wielu deweloperów z du ym do wiadczeniem orazwysokim poziomem umiej tno ci w zakresie modelowania dziedziny. Je elido wiadczenie jest bardzo du e i sami in ynierowie twierdz , e wzorce taktycznes najlepszym wyborem, to zaufanie ich opiniom ma sens. Uczciwi dewelope-rzy, niezale nie od tego, jak do wiadczeni, w okre lonej sytuacji powiedz , czyrozwijanie modelu dziedziny jest, czy nie jest najlepszym wyborem.

Typ samej dziedziny biznesu nie jest automatycznie czynnikiem decyduj cymo wyborze podej cia do projektowania. Zespó powinien wzi pod uwag wa nekwestie, które pomog w podj ciu ostatecznej decyzji. Poni ej zamieszczono krótklist bardziej szczegó owych parametrów decyzyjnych, które w mniejszym b dw wi kszym stopniu s dopasowane do wymienionych wcze niej bardziej ogól-nych wskazówek.

Czy eksperci dziedziny s dost pni i czy jeste przekonany o s uszno ci ideitworzenia zespo u skupionego wokó nich?

Czy z o ono okre lonej dziedziny biznesu, która jest dzi stosunkowo niska,z czasem wzro nie? Istnieje ryzyko stosowania Skryptu Transakcji1 w odnie-sieniu do z o onych aplikacji. Je eli u ywasz Skryptu Transakcji teraz, to czywtedy, gdy Kontekst stanie si z o ony, potencjalna refaktoryzacja do beha-wioralnego modelu dziedziny b dzie wykonalna?

1 W tym opisie uogólni em poj cia. Na tej li cie u y em terminu „Skrypt Transakcji”

do reprezentacji podej innych ni modelowanie dziedziny.







Czy u ycie taktycznych wzorców DDD u atwi integracj z innymi Kontek-stami Ograniczonymi — zarówno nabytymi na zewn trz, jak i rozwijanymisamodzielnie?

Czy w przypadku u ycia wzorca Skrypt Transakcji rozwijanie oprogramo-wania naprawd b dzie prostsze i b dzie wymaga o mniej kodu? (Do wiad-czenie z obydwoma podej ciami udowadnia, e w wielu przypadkach sto-sowanie Skryptu Transakcji wymaga takiej samej albo wi kszej ilo ci kodu.To prawdopodobnie wynika z niedostatecznie dobrego zrozumienia z o ono cidziedziny i innowacyjno ci modelu w fazie planowania projektu. Niedocenia-nie z o ono ci dziedziny i jej innowacyjno ci zdarza si naprawd cz sto).

Czy kluczowa cie ka i plan czasowy pozwalaj na jakikolwiek narzut wyma-gany dla inwestycji taktycznej?

Czy taktyczna inwestycja w Dziedzin G ówn ochroni system przed wp y-wami zmian w architekturze? Zastosowanie Skryptu Transakcji mo e nara-zi system na takie zmiany (modele dziedziny cz sto s trwa e, architekturanatomiast mo e wywiera negatywny wp yw na inne warstwy).

Czy klienci (u ytkownicy) skorzystaj z czystszego, trwalszego podej cia doprojektowania, czy te ich aplikacj b dzie mo na nied ugo zast pi goto-wym rozwi zaniem? Inaczej mówi c, czy istniej jakiekolwiek powody, abyrozwija produkt jako w asn aplikacj (us ug )?

Czy rozwijanie aplikacji (us ugi) z wykorzystaniem taktycznych wzorców DDDb dzie trudniejsze ni skorzystanie z innych podej — na przyk ad SkryptuTransakcji (kluczowe znaczenie dla udzielenia odpowiedzi na to pytanie majpoziom umiej tno ci i dost pno ekspertów dziedziny)?

Gdyby my dysponowali kompletnym zestawem narz dzi do tego, by móczastosowa DDD, to czy zdecydowaliby my si na zastosowanie jakiegoinnego podej cia (niektóre czynniki sprawiaj , e praktyczny staje si okre-lony model utrwalania, na przyk ad mapowanie obiektowo-relacyjne, pe na

serializacja Agregatów i utrwalanie, Magazyn Zdarze lub framework wspie-raj cy taktyczne wzorce DDD; mog istnie tak e inne czynniki)?

Ta lista nie zosta a sporz dzona z my l o Twojej dziedzinie. Prawdopodob-nie zdo a by poda kilka dodatkowych kryteriów. Zdajesz sobie spraw z przy-czyn stosowania najlepszych i najpot niejszych metod pozwalaj cych na osi -gni cie jak najwi kszych korzy ci. Znasz tak e swoj bran i masz obrazu ywanych technologii. W efekcie ko cowym to klient biznesowy ma by zado-wolony, a nie u ytkownicy obiektów i technicy. Nale y dokonywa m drychwyborów.







DDD nie jest z o onym procesemW adnym razie nie staram si sugerowa , e prawid owe stosowanie DDDprowadzi do „ci kiego” procesu, obfituj cego w skomplikowane proceduryi obszern dokumentacj , któr trzeba utrzymywa . Metodyka DDD taka niejest. Powinna ona dobrze pasowa do dowolnego frameworka projektowaniaAgile, którego zespó u ywa, takiego jak Scrum. Jego zasady projektowania kon-centruj si raczej na szybkich udoskonaleniach rzeczywistego modelu opro-gramowania zgodnie z podej ciem „najpierw test”. W przypadku konieczno ciopracowania nowego obiektu dziedziny, na przyk ad Encji albo Obiektu War-to ci, nale y zastosowa podej cie „najpierw test”, które opisano poni ej.

1. Napisz test, który demonstruje sposób u ycia nowego obiektu dziedziny przezklienta modelu dziedziny.

2. Stwórz nowy obiekt dziedziny z kodem, który wystarcza do tego, aby testsi skompilowa .

3. Refaktoryzuj zarówno test, jak i obiekt dziedziny tak d ugo, a test zaczniew a ciwie reprezentowa sposób, w jaki klient powinien u ywa obiektu,a obiekt dziedziny b dzie mia prawid owe sygnatury metod reprezentuj cezachowania.

4. Implementuj poszczególne zachowania obiektu tak d ugo, a test zacznieprzechodzi . Jednocze nie refaktoryzuj obiekt dziedziny do czasu, a zostanwyeliminowane wszelkie niew a ciwe duplikaty w kodzie.

5. Zademonstruj kod cz onkom zespo u, w cznie z ekspertami dziedziny, abyzyska pewno , e test u ywa obiektu dziedziny zgodnie z aktualnym zna-czeniem J zyka Wszechobecnego.

Mo na by s dzi , e powy szy proces nie ró ni si w aden sposób od podej-cia „najpierw test”, które stosujemy na co dzie . By mo e jest ono troch inne,

ale w gruncie rzeczy jest takie samo. Faza testu nie usi uje udowodni z absolutnpewno ci , e model jest „kuloodporny”. W tym celu pó niej zostan dodanekolejne testy. Najpierw chcemy skupi si na tym, jak model b dzie u ywanyprzez klientów. Te testy steruj projektem modelu. Dobr wiadomo ci jest to,e na tym w gruncie rzeczy polega zwinne podej cie do projektowania. Meto-

dologia DDD promuje lekki rozwój, a nie ceremonialny, zawi y projekt „z góry”.Pod tym wzgl dem to podej cie niczym si nie ró ni od powszechnych tech-nologii Agile. Zatem o ile nie s dz , aby poprzednio opisane kroki o wieci yczytelnika w zakresie metodologii Agile, o tyle uwa am, e wyja ni y pozycjmetod DDD, które powinny by u ywane zgodnie z zasadami Agile.

Na dalszym etapie projektu dodamy testy, które zweryfikuj poprawnonowego obiektu dziedziny z ka dej mo liwej (i praktycznej) perspektywy. W tymmomencie interesuje nas jedynie poprawno wyra enia poj cia dziedziny, które






FI K CJ A Z D U D A W K R E A LI ZM U 83

jest uciele nione w nowym obiekcie. Czytanie demonstracyjnego kodu testuw stylu klienta musi ujawni w a ciw wyrazisto u ywania J zyka Wszech-obecnego. Eksperci dziedziny, którzy nie s „techniczni”, powinni móc czytakod (z pomoc dewelopera) na tyle dobrze, aby uzyska jasne wra enie, emodel osi gn cel, jaki zespó sobie postawi . To sugeruje, e dane testu musz byrealistyczne oraz musz wspiera i poprawia po dan ekspresywno . W prze-ciwnym razie eksperci dziedziny nie b d w stanie obiektywnie oceni imple-mentacji.

Pokazan metod zwinn „najpierw test” nale y powtarza tak d ugo, auzyskamy model, który dzia a zgodnie z zadaniami wyznaczonymi dla bie cejiteracji. Kroki wymienione wcze niej s zgodne ze zwinnymi zasadami progra-mowania. Reprezentuj regu y pierwotnie promowane przez zwolenników Pro-gramowania Ekstremalnego. Stosowanie zwinnych regu projektowania nieeliminuje adnych zasadniczych wzorców i praktyk DDD. One nie le do siebiepasuj . Oczywi cie mo na korzysta z pe nej metodologii DDD bez stosowaniazasad projektowania „najpierw test”. Zawsze mo na opracowa testy dla istniej -cych obiektów modelu. Trzeba jednak pami ta , e projektowanie z perspek-tywy klienta modelu dodaje bardzo po danego wymiaru.

Fikcja z du dawk realizmuPodczas rozwa ania na temat sposobu jak najlepszej prezentacji przewodnikaw a ciwej implementacji DDD stara em si dostarczy uzasadnienia dla wszyst-kiego, co zgodnie z tym, co powiedzia em, powinno by zrobione. To oznacza odostarczanie odpowiedzi nie tylko na pytanie „jak?”, ale tak e „dlaczego?”.Przysz o mi na my l, e przyjrzenie si kilku projektom jako studiom przypadkóww a ciwie zilustruje powody, dla których co zasugerowa em oraz pokaza em,e w a ciwe u ycie DDD sprosta powszechnie wyst puj cym wyzwaniem.

Czasami atwiej jest spojrze na problemy, jakie napotykaj inne zespo yprojektowe, i uczy si na podstawie ich niew a ciwego u ywania DDD, niszuka problemów we w asnym projekcie. Je li uda nam si rozpozna niedo-ci gni cia w pracy innych, z pewno ci b dziemy równie w stanie oceni , czypod amy w tym samym, niepewnym kierunku albo nawet tkwimy po uszyw takim samym bagnie. Wiedz c, dok d zmierzamy lub gdzie ju jeste my,mo emy wykona precyzyjne korekty w celu wyeliminowania problemów i unik-ni cia powtórzenia takich samych k opotów w przysz o ci.

Zamiast prezentowa seri rzeczywistych projektów, nad którymi praco-wa em — i tak nie móg bym otwarcie o nich mówi — zdecydowa em si u ytroch fikcji bazuj cej na realnych sytuacjach; przytrafi y si one zarówno mniesamemu, jak i innym. W ten sposób zdo a em utworzy doskona y stan wydarzepozwalaj cych na zademonstrowanie powodów, dla których okre lone podej cie







do implementacji sprawdza si najlepiej albo przynajmniej pozwala najlepiejsprosta wyzwaniom towarzysz cym stosowaniu DDD.

Zatem studia przypadków nie opieraj si wy cznie na fikcji. Zaprezento-wano w nich fikcyjne przedsi biorstwo z prawdziwej bran y, fikcyjne zespo yw przedsi biorstwie z realnym oprogramowaniem do zbudowania i wdro eniaoraz rzeczywiste wyzwania i wynikaj ce z nich problemy razem z realnymi roz-wi zaniami. Nazwa em to fikcj z du dawk realizmu. Pisanie w tym styluwydaje mi si ca kiem skuteczne. Mam nadziej , e czytelnik na tym skorzysta.

Podczas prezentowania dowolnego zbioru przyk adów trzeba ograniczy jegozakres, by opis by praktyczny. W przeciwnym razie, z powodu nadmiernejobj to ci, zarówno nauczanie, jak i uczenie si b d utrudnione. Przyk ady niemog by tak e nadmiernie uproszczone, poniewa to powodowa oby pomi-ni cie istotnych aspektów. W celu znalezienia odpowiedniej równowagi doprezentowania przyk adów wybra em tzw. obszar niezagospodarowany (ang.greenfield)2.

Przygl daj c si projektom w ró nej fazie, zauwa ymy problemy, z jakimiborykaj si zespo y, jak równie sukcesy, które zespo y odnosz . DziedzinaG ówna, która stanowi sedno przyk adów, jest wystarczaj co z o ona, by mo naby o bada DDD z ró nych perspektyw. Nasze Konteksty Ograniczone u ywajjednego albo kilku innych Kontekstów Ograniczonych, co pozwala bada zagad-nienia integracji z DDD. Pomimo to na podstawie trzech przyk adowych modelinie da si zademonstrowa wszystkich aspektów projektowania strategicznego,jakie wyst puj powszechnie w rodowisku „obszaru br zowego” (ang. brown-field) — tzn. takiego, w którym dzia a wiele tradycyjnych systemów. Staramsi , by te mniej atrakcyjne regiony nie zosta y zupe nie pomini te, tak jakby by ynieistotne. Tam, gdzie jest to wskazane, odbiegam od g ównych obszarów przy-k adów i studiuj obszary, w przypadku których mo na skorzysta ze wskazó-wek DDD w dodatkowy sposób, przynosz cy wi ksze korzy ci.

W dalszej cz ci tekstu zaprezentuj czytelnikom firm i opowiem trocho zespo ach oraz projektach, nad którymi one pracuj .

Firma SaaSOvation, jej produkty i wykorzystanie DDDPrzyk adowa firma nazywa si SaaSOvation. Jak sugeruje nazwaprzedsi biorstwa, SaaSOvation zajmuje si rozwojem aplikacjiSaaS (ang. Software as a Service — dos . oprogramowanie jakous uga). Firma SaaSOvation zapewnia hosting swoich produk-tów. Korzystaj z nich firmy, które dokonaj subskrypcji. Planbiznesowy przedsi biorstwa obejmuje rozwój dwóch produktów.

2 Autor ma na my li zupe nie nowy temat, gdzie projektowanie odbywa si od zera.

Jest to tzw. obszar zielony (ang. greenfield), w przeciwie stwie do „obszaru br zowego”(ang. brownfield), tzn. sytuacji, w której ju wyst puj jakie systemy — przyp. t um.






FI K CJ A Z D U D A W K R E A LI ZM U 85

Flagowy produkt firmy nosi nazw CollabOvation. To aplikacja wspomagaj ca wspó -prac w firmie. Wykorzystano w niej w asno ci najpopularniejszych sieci spo eczno-ciowych. Obejmuje to fora, wspó dzielone kalendarze, blogi, komunikatory, wiki, tablice

og osze , mechanizmy zarz dzania dokumentami, powiadamiania i alarmowania, ledzeniaaktywno ci oraz czytników RSS. Wszystkie te narz dzia wspó pracy grupowej koncen-truj si na potrzebach firm korporacyjnych. Pozwalaj zwi kszy produktywnow mniejszych projektach, w wi kszych programach oraz na przestrzeni wielu jednostekbiznesowych. Wspó praca w biznesie jest wa na ze wzgl du na tworzenie i wspomaganiesynergicznej atmosfery we wspó czesnej, zmieniaj cej si i czasami niepewnej, ale dyna-micznej, gospodarce. Wszystko, co mo e przyczyni si do zwi kszenia produktywno ci,transferu wiedzy, promowania wspó dzielenia my li technicznej i asocjacyjnego zarz dzaniaprocesem twórczym — tak by mo na by o w a ciwie wykorzysta jego rezultaty — b dzieczynnikiem tworz cym przewag w równaniu opisuj cym sukces przedsi biorstwa. ProduktCollabOvation stanowi dla klientów warto ciow propozycj i jest wyzwaniem dla jegodeweloperów.

Drugi produkt, pod nazw ProjectOvation, to kluczowa Dziedzina G ówna. Narz -dzie s u y do zarz dzania projektami Agile z wykorzystaniem metodyki Scrum. Jest toframework wspomagaj cy iteracyjne i przyrostowe zarz dzanie projektem. ProjectOva-tion oferuje funkcjonalno ci zgodne z tradycyjnym modelem zarz dzania projektemScrum — uwzgl dnia produkt, w a ciciela produktu, zespó , pozycje rejestru zada dowykonania, zaplanowane wydania i sprinty. Szacowanie pozycji rejestru jest realizowaneza pomoc kalkulatorów warto ci biznesowych, wykorzystuj cych analizy typu koszt-zysk.ProjectOvation zmierza w kierunku zapewnienia jak najlepszego wsparcia dla metodykiScrum. Zak ada si jednak, e system SaaSOvation przyniesie wi ksze korzy ci.

Produkty CollabOvation i ProjectOvation nie rozwijaj si wed ug zupe nie oddziel-nych cie ek. Cz onkowie zespo u SaaSOvation i rada doradców przewidzieli innowacjpolegaj c na dostarczeniu narz dzi wspó pracy do realizacji zwinnych technik rozwojuoprogramowania. Zgodnie z tym funkcjonalno systemu CollabOvation b dzie ofero-wana jako opcjonalne rozszerzenie produktu ProjectOvation. Nie ulega w tpliwo ci, edodatek dostarczaj cy narz dzi wspó pracy do wspomagania planowania projektu,dyskutowania o cechach funkcjonalnych i historyjkach, prowadzenia dyskusji grupoweji zapewniania wsparcia w zespole oraz pomi dzy zespo ami b dzie popularny. FirmaSaaSOvation przewiduje, e funkcje CollabOvation doda ponad 60 procent subskry-bentów systemu ProjectOvation. Trzeba pami ta , e taka dodatkowa sprzeda cz stoprowadzi do nowej sprzeda y dodatku jako odr bnego produktu. Gdy po ustanowieniukana u sprzeda y zespo y rozwoju oprogramowania zobacz mo liwo ci wspó pracyw swoim zestawie narz dzi zarz dzania projektem, ich entuzjazm wp ynie na pe ne przy-j cie kompletnego zestawu narz dzi wspó pracy w ca ej firmie. Dzi ki temu podej ciudo sprzeda y firma SaaSOvation prognozuje dalej, e minimum 35 procent ca ej sprze-da y produktu ProjectOvation b dzie prowadzi o do pe nego wdro enia produktu Col-labOvation. Kierownictwo uwa a to za konserwatywn ocen , ale je li przewidywaniaoka si trafne, b dzie to oznacza o du y sukces.

Najpierw skompletowano zespó rozwoju produktu CollabOvation. Znalaz o si w nimkilku wprawionych weteranów, ale wi kszo zespo u stanowili rednio zaawansowanideweloperzy. Na pierwszych spotkaniach wskazano metodyk DDD jako proponowanepodej cie do projektowania i rozwoju. Jeden z dwóch starszych deweloperów u ywaminimalnego zbioru wzorców DDD w poprzednim projekcie u by ego pracodawcy. Ze







sposobu, w jaki opisa swoje do wiadczenia zespo owi, bardziej do wiadczony dewe-loper korzystaj cy z DDD wysnu by wniosek, e w tym projekcie nie stosowano w pe nimetod DDD. To, czego u ywano czasami, okre la si terminem DDD-Lite.

DDD-Lite to mechanizmy dobierania podzbioru taktycznych wzorców DDD, ale bezpo wi cania pe nej uwagi odkrywaniu, opracowywaniu i poprawianiu J zyka Wszech-obecnego. Ponadto w technice tej zazwyczaj pomija si u ywanie Kontekstów Ograniczo-nych i Mapowania Kontekstu. DDD-Lite koncentruje si w wi kszym stopniu na aspektachtechnicznych, a najwa niejszym celem jest rozwi zywanie problemów technicznych. Mo eto przynosi korzy ci, ale ogólnie rzecz bior c, nie s one tak du e jak w przypadku sto-sowania technik modelowania strategicznego. Firma SaaSOvation postanowi a skorzy-sta z DDD-Lite. W tej sytuacji takie post powanie szybko doprowadzi o do problemów,poniewa zespó nie rozumia Poddziedzin ani mo liwo ci wyra nego okre lenia Kon-tekstów Ograniczonych i osi ganego dzi ki temu bezpiecze stwa.

Ale mog o by gorzej. Firma SaaSOvation w a ciwie unikn a najwi kszych pu apekzwi zanych z u ywaniem DDD-Lite, ze wzgl du na to, e jej dwa g ówne produkty two-rzy y naturalny zbiór Kontekstów Ograniczonych. Dzi ki temu modele produktów Collab-Ovation i ProjectOvation mog y by formalnie posegregowane. Ale to by tylko przypadek.To nie znaczy o, e zespó rozumia Kontekst Ograniczony. W a nie dlatego wyst pi yproblemy. Albo si czego uczymy, albo spotyka nas niepowodzenie.

Na szcz cie mo emy skorzysta z przeanalizowania niekompletnego u yciaDDD w firmie SaaSOvation. Zespó w ko cu wyci gn wnioski ze swoichb dów i w pe niejszy sposób zastosowa techniki projektu strategicznego. Napodstawie udoskonale wprowadzonych przez zespó CollabOvation dowiemysi tak e, e utworzony pó niej zespó produktu ProjectOvation skorzysta naretrospektywach wczesnych warunków swojego siostrzanego i partnerskiegoprojektu. Wi cej informacji na ten temat mo na uzyska w opisie wzorców Pod-dziedzina (2) i Kontekst Ograniczony (2), jak równie Mapa Kontekstu (3).

PodsumowanieW niniejszym rozdziale zaprezentowano do zach caj ce wprowadzenie w meto-dyk DDD. S dz , e do tej chwili czytelnik przekona si , i zespó mo e odniesukces, je li zastosuje zaawansowan technik projektowania oprogramowania.Zgadzam si z tym.

Oczywi cie nie mam zamiaru nadmiernie upraszcza obrazu. Wdro enie DDDwymaga sporego wysi ku wielu osób. Gdyby to by o atwe, wszyscy pisaliby






PO DS UMO WA NI E 87

doskona y kod, a przecie dok adnie wiemy, e tak si nie dzieje. Zatem przy-gotuj si na wysi ek. Warto b dzie go podj , poniewa dzi ki temu projektb dzie wyra a dok adnie to, co robi oprogramowanie.

Oto czego nauczy e si dotychczas:

Odkry e , co dla Twoich projektów i zespo ów mo e przynie zastosowanieDDD do zmagania si ze z o ono ci dziedziny.

Dowiedzia e si , jak oceni , czy Twój projekt kwalifikuje si do zainwesto-wania w DDD.

Przeanalizowa e popularne alternatywy dla DDD i dowiedzia e si , dlaczegostosowanie tego podej cia cz sto prowadzi do problemów.

Zapozna e si z podstawowymi za o eniami DDD i jeste przygotowany dowykonania pierwszych kroków w swoim projekcie.

Dowiedzia e si , jak zaprezentowa DDD swojemu kierownictwu, ekspertomdziedziny i technicznym cz onkom zespo u.

Teraz jeste uzbrojony w wiedz potrzebn do odniesienia sukcesu podczasstawiania czo a wyzwaniom DDD.

Oto czym zajmiemy si dalej. Nast pne dwa rozdzia y dotycz najwa niejszychaspektów projektowania strategicznego. Kolejny rozdzia natomiast dotyczy archi-tektury oprogramowania tworzonego z wykorzystaniem metodyki DDD. Tonaprawd wa ne zagadnienia, z którymi trzeba si zapozna przed przyst pie-niem do lektury dalszych rozdzia ów, dotycz cych modelowania taktycznego.












SkorowidzA

Abstrakcja, 182abstrakcyjny widok

interakcji, 362Activate tenant, 255Adaptery, 155, 466

Portu, 524renderowania, 589

adres URI, 154Agile, 130, 140Agregat, 39, 73, 116, 132,

198, 212, 350, 411,611BacklogItem, 427, 437Calendar, 459Customer, 618Discussion, 459Forum, 459Metody Fabrykuj ce, 459Product, 459ProductOwner, 546TeamMember, 546Tenant, 459

Agregatyjako klastry, 413publikowanie stanu

wewn trznego, 584du e, 414ma e, 420ukierunkowane, 641

aktualizowanie MagazynuZdarze , 218

aktywno ci partnerskie, 211Aktywny Rekord, 510algorytm CEB, 571AMQP, 178analiza

modelu dla biznesu, 65Poddziedzin, 145projektu, 436projektu alternatywnego,

442

Anemiczny ModelDziedziny, 56, 57,248, 329

API, 58, 552aplikacja, 115, 579, 580

CollabOvation, 85ProjectOvation, 85RIA Web 2.0, 589

architekt, 47Architektura, 38, 115

Portów i Adapterów, 175przedsi biorstwa, 72Sterowana Zdarzeniami,

EDA, 150, 201Sze ciok tna, 38, 175–

178, 333, 403Sze ciok tna wspieraj ca

SOA, 183Ukierunkowana na

Us ugi, SOA, 181,327

Warstwowa, 170, 403,407

Asembler DTO, 194Asercje, 307Authentication service, 255autodelegacja, 303autohermetyzacja, 246Autonomia, 182Autonomiczne Us ugi

i Systemy, 367

Bbaza danych, 114

MySQL, 238, 322, 637Bezstanowo , 182BI, business intelligence,

310biblioteka

Hibernate, 59, 243RabbitMQ, 389

Bie ca Dziedzina G ówna,148

bie cy rejestr, current log,376–378

BLOB, binary large object,639

b d bufora Coherence, 493bogate aplikacje

internetowe, RIA, 582brak mechanizmów

technicznych, 434Brama do Danych Tabeli,

510Budowniczy, 282, 457Bufory Protoko u, 408,

523, 648

CCEB, Capped Exponential

Back-Off, 571cechy

Encji, 252klienta HTTP, 188serwera HTTP, 187Warto ci, 279

celebiznesowe, 67strategiczne, 184

Checks, 269Ci g e Zapytania,

Continuous Query, 222CLR, common language

runtime, 120Coherence

implementacjaRepozytorium, 488

testowanieRepozytorium, 511

CQRS, Command-QueryResponsibilitySegregation, 191, 193,588






662 SKO ROWI DZ

CQS, Command QuerySeparation, 191, 287,416

CVS, 215czas generowania

identyfikatora, 241ycia Encji, 246

cz onek zespo u, 445

Ddane BI, 167DDD, Domain-Driven

Design, 43Deactivate tenant, 255debugowanie, 650deduplikacja zdarze ,

356, 392definicja biznesu, 70deserializacja, 495deweloper, 71,101

m odszy, 46starszy, 47zaawansowany, 47

DIP, Dependency InversionPrinciple, 581

D ugotrwa e Procesy, 551,563

dobra otrzymane, 95dostarczanie

Typów Standardowych,297

warto ci biznesowych,50

dost pdo Agregatu, 614do atrybutów, 75

dost pno systemów, 623DPO, Domain Payload

Object, 585DRY, Don’t Repeat

Yourself, 49DSL, Domain Specific

Language, 652DTO, Data Transfer

Objects, 191, 305, 583,643

dystrybucja, 429

dzia aniawielopodmiotowe, 429

dzia anieKontekstu Zarz dzania

Projektem Agile, 156stra nika, 247

Dziedzina, 90, 103, 404,519G ówna, 53, 90, 98,

105, 652G ówna Scrum, 412

dzier awca, tenant, 129, 256

EEDA, Event-driven

architecture, 201edycja u ytkownika, 589EJB, Enterprise JavaBeans,

605Eksperci dziedziny, 45, 71,

349Encja, 73, 99, 211, 227,

448Customer, 261Tenant, 251User, 251

Encryption Service, 253ETL, 200

FFabryka, 172, 233, 265,

417, 457Abstrakcyjna, 457Us ug, 176, 337, 465,

604fabryki w modelu

dziedziny, 457Fasada, 591

Sesji, 605faworyzowanie Obiektów

Warto ci, 449firma SaaSOvation, 84,

121, 165format

GPB, 149MongoDB, 494StoredEvent, 372

framework, 59Coherence, 493Hibernate, 307RabbitMQ, 390Spring, 337, 503, 596TopLink, 484

fronton, 177funkcja

LAST_INSERT_ID(),239

Ggarbage collection, 278generowanie

identyfikatora, 241, 235kontraktu, 652migawki, 632

getter, 59Git, 215GPB, Google Protocol

Buffers, 149granice modeli, 72

Hhandler

komunikatów, 206ValidationNotificationH

andler, 271Polece , 197, 621

HATEOS, 188Hibernate


wyj tki, 481hierarchia

nazw, 401obiektów, 469Obiektów Warto ci, 292typów, 506

historyjki u ytkownika, 67hurtownia danych, 200

IIDE, 58, 119idempotencja wymiany, 391idempotentno obiektu

dziedziny, 394






SKO ROWI DZ 663

Idempotentny Odbiorca,393

identyfikatordostarczany przez

u ytkownika, 230generowany przez

aplikacj , 231generowany przez

mechanizmutrwalania, 235

GUID, 231przypisany przez inny

KontekstOgraniczony, 239

to samo ci, 316to samo ci Agregatu,

421, 424UUID, 231, 233zast pczy, 245Zdarzenia, 388

implementacja, 302, 447Repozytorium, 484klienta REST, 533Magazynu Zdarze , 633Metody Fabrykuj cej,

461metody saveCustomer(),

63publikowania, 382, 390Repozytorium, 175,

342, 476, 488, 494spójno ci ostatecznej,

443Us ugi Aplikacji, 613zasobu RESTful, 530

implementacje interfejsów,173

informacjeo cz onkach zespo u,

540o w a cicielach

produktu, 540infrastruktura, 604

Coherence, 489komunikatów, 576obs ugi komunikatów,

366instrukcja SELECT, 195Integracja, 120

KontekstówOgraniczonych, 135,155, 159, 380

z KontekstemTo samo i Dost p,153

z KontekstemWspó praca, 156

integralno odwo a , 245integrowanie

KontekstówOgraniczonych, 519

KontekstówOgraniczonych, 239,458, 465, 467, 580

Inteligentny UI, 115interakcja, 362interesariusz, 106interfejs

CRUD, 510IAppendOnlyStore, 635,

636, 637, 638klasy DomainEvent, 352klasy

NotificationService,383

metody saveCustomer(),63

Process, 574ProductRepository, 489Repozytorium, 476,

477, 499SOAP, 183Ujawniaj cy Zamiar, 254u ytkownika, UI, 115,

122, 582interfejsy

ni szego poziomu, 634wy szego poziomu, 634

IoC, inversion-of-control,503

iterowanie Zdarzenia, 362

JJavaBean, 305jawna kopia przed

zapisem, 475JAX-RS, 180, 189

J dro Wspó dzielone, 141,523, 651

JDBC, 239Jednostka Pracy, 470, 485j zyk

DSL, 652Opublikowany, 142,

149, 190, 465UML, 66Visual Basic, 58Wszechobecny, 37, 63,

64, 68, 122j zyki funkcyjne, 655

Kkarty punktów DDD, 53katalog produktów, 90kierownik, 211klasa

AuthenticationService,332, 335

BacklogItem, 114, 340,406

BacklogItemRepository,340

BusinessPriority, 302BusinessPriority

Calculator, 344BusinessPriorityTotals,

300CalendarRepository,

474Collaborator, 537Customer, 67, 261CustomerInvoice

Written, 652DomainEvent, 352, 374DomainEventPublisher,

359EventStore, 373ExchangeListener, 543,

544Forum, 126Group, 317GroupMember, 316HibernateCalendar

EntryRepository,482






664 SKO ROWI DZ

klasaHibernateUserRepository,

505java.util.Collection, 499MD5EncryptionService,

336MessageParameters, 390MessageProducer, 391MongoRepository, 497Notification, 385, 389NotificationService,

382, 383NumberFormat, 300Release, 413Rzutu, 643ServiceProvider, 509SpringHibernateSession

Provider, 480StoredEvent, 374User, 264, 295

klasy abstrakcyjnewielokrotnego u ytku,403

klient, 451HTTP typu RESTful,

188REST, 533

kod, 63kolekcja Set

groupMembers, 318Kometa, 201komponent

ApplicationContext, 607bean sessionProvider,

504bean tenantIdentity

Service, 606DomainEventPublisher,

198PhoneNumberExecutive,

210PhoneNumbersPublisher,

206PhoneNumberState

Tracker, 212komponenty

EJB, 605techniczne, 119

Komponowalno , 182

kompozycjaKontekstów

Ograniczonych, 602wielu modeli, 602

komunikat, 205Konformista, 141, 530konstruktor, 263

bez argumentów, 307klasy Warto ci, 283kopiuj cy, 304

KontekstBank, 110Magazyn, 108Ograniczony, 37, 63, 90,

109, 114, 119, 184,230, 291, 365, 409,519

kompozycja, 602przekazywanie

komunikatów, 539zasoby RESTful, 529

Optymalne Nabywanie,107, 108

Rozliczenia, 110To samo i Dost p,

129To samo i Dost p,

128, 153, 154, 534Wspó praca, 121, 125,

150, 156, 412, 534,559

Zarz dzania ProjektemAgile, 153

Zarz dzanie ProjektemAgile, 130, 405, 407

kontenerna dane, 63odwracania sterowania,

337komponentów, 605odwracania sterowania,

503Kontrakt us ugi, 182kontrakty terminowe,

futures, 111konwencje nazewnictwa

Modu ów, 401koszt Agregatu, 438

Llambda, 625leniwe adowanie, 420Logiczna Mapa

T umaczenia, 152logiczny podzia

Poddziedzin, 92LSP, Liskov Substitution

Principle, 507Lu ne sprz enia, 182

adowanie Agregatów, 630amanie regu , 433

Mmagazyn

BLOB, 640danych NoSQL, 486Data Fabric, 219Fabric, 220, 221GemFire, 222Grid, 219IEventStore, 615MongoDB, 487Riak, 487Zdarze , 216, 241, 370,

372, 611, 615implementacja, 633

Magazynowanie Zdarze ,215, 216, 217, 218, 350

Manifest Agile, 130Mapa

Kontekstu, 519trzech Kontekstów, 143

Maper Danych, 510Mapowanie

Kontekstu, 120, 240ORM, 313

Mapy Kontekstu, 37, 69,96, 116, 135

maszyny stanu procesu, 563mechanizm

autohermetyzacji, 246Ci g ych Zapyta , 222generowania kodu, 297






SKO ROWI DZ 665

leniwego adowania, 420od miecania, 278ORM, 314OSIV, 586przekazywania

komunikatów, 539Publikuj- -Subskrybuj,

520utrwalania, 235utrwalania Magazynu

Zdarze , 392mechanizmy komunikacji,

137Mediator, 171, 584mened er, 48Mercurial, 215metadane, 215metoda

add(), 480addAll(), 480AllProductsOfTenant(),

494, 499Apply(), 619assignUser(), 541authorFrom(), 535calendarEntryOfId(),

478checkForTimedOut

Processes(), 566disable(), 548enable(), 548enableProductOwner(),

546enablingOn(), 549equals(), 242, 306exchangeName(), 544Execute(), 624findNotificationLog(),

384findTenant(), 601GET, 188informProcessTimed

Out(), 566initiateDiscussion(), 561listUnpublished

Notifications(), 389LockCustomer(), 621maintainMembers(), 155Mutate(), 617, 624

newProductWith(), 553nextIdentity(), 238, 448,

483, 491productOfId(), 513, 516provisionTenant(), 600publish(), 362PublishNotifications(),

388, 391registerNewObject(), 485registerObject(), 486remove(), 317, 480removeAll(), 480ReplayEvents(), 632requestDiscussion(), 556requestDiscussionIfAvail

able(), 553save(), 497, 498saveCustomer(), 61, 63saveOrUpdate(), 485scheduleCalendarEntry(),

462serialize(), 497session(), 506setAddress(), 267setRatings(), 280setUp(), 516size(), 499store(), 374subscribedToEventType(),

373tenant(), 595toGroupMember(), 295validate(), 273write(), 601

metodologiaDDD, 70, 82Scrum, 130, 415

metodyabstrakcyjne, 543Fabryki, 233Fabrykuj ce, 458Fabrykuj ce wewn trz

Rdzenia Agregatu,459

HTTP, 188, 529idempotentne, 188statyczne, 326

metodyka, Patrzmetodologia

migawka, 217Agregatu, 633stanu, 631

minimalizm integracji, 291model, 114

Dziedziny, 38, 46, 359,404

polece , 192polece uruchamia

zachowania, 198Prezentacji, 171, 305,

587, 590, 591Scrum, 75Widoku, 587wielokrotnego u ytku,

140zapyta , 194

modelowanieci g e, 72dziedziny, 78Funkcji-Bez-Skutków-

Ubocznych, 251iteracyjne, 72strategiczne, 37taktyczne, 39us ugi w dziedzinie, 333Zdarze , 351zwinne, 72

Moderator, 292Modu , 94, 116, 160, 173,

397domain.model, 403Kontekstu Zarz dzanie

Projektem Agile, 404przed Kontekstem

Ograniczonym, 409Tabeli, 510

modu ypotomne, 405rodzica, 405warstwy Aplikacji, 408

modyfikowanieegzemplarza agregatu,

364identyfikatorów Encji,

246MoM, message-oriented

middleware, 327






666 SKO ROWI DZ

MongoDBimplementacja

Repozytorium, 494Monter DTO, 584

Nnadu ywanie typów

Warto ci, 284narz dzia

modelowania, 73pomocnicze, 647raportowania BI, 310wspó pracy biznesowej,

121narz dzie RabbitMQ, 155natywny typ bazy danych,

243nawigowanie po modelu,

426nazewnictwo

klas implementacyjnych,336

KontekstówOgraniczonych, 100

metod, 305Modu ów w modelu,

401, 402niedost pna infrastruktura

komunikatów, 576niejawna kopia

przy odczycie, 474przy zapisie, 474

niesko czonaskalowalno , 429

niezmienna Warto , 284niezmienniki, 263

fa szywe, 419modelu, 418

niezmienno , 280Warto ci, 303Zdarze , 649

Oobiekt

BacklogItem, 353bean, 479BLOB, 639

BSONSerializer, 496BusinessPriority, 300Calendar, 462CalendarEntry, 460, 461CommittedBacklogItem,

431Customer, 60, 262, 643Date, 547DB, 497Discussion, 463, 538, 562DomainEvent, 374DPO, 585dziedziny, 82EventStore, 385ExclusiveDiscussion

CreationListener,572

Forum, 558, 562ForumService, 559GroupMember, 321GroupMemberType, 295IdentityAccessEvent

Processor, 372IProvideCustomer

BillingView, 645JMX TimerMBean, 391MemberService, 155MessageProducer, 391Moderator, 113, 291MonetaryValue, 282MongoDatabaseProvider,

497, 498NamedCache, 490Notification, 383, 389,

524NotificationListener,

391NotificationReader, 528,

538NotificationService, 387,

392POJO, 59Process, 574, 575Product, 131, 415, 421,

425ProductDiscussion

RequestedListener,564

ProductService, 569Rachunek, 110

Session, 481, 483Sprint, 355Stanu, 295StoredEvent, 374TestableNavigable

DomainEvent, 527ThingName, 283TimeSpan, 483Transferu Danych,

DTO, 305, 643UnitOfWork, 484ValueCostRiskRatings,

312WarbleValidator, 271Warto ci, 99, 290, 297,

422, 501Warto ci Collaborator,

538Warto ci

UserDescriptor, 332Obiekty

Dost pu do Danych, 509DTO, 583Enum, 320Polece , 598ledz ce, 565

transferu danych, 583transferu danych, DTO,

191Warto ci, 73, 158, 277,

449, 527, 649obliczenia typu BOTE, 438obowi zki, 258Obserwator, 171, 198, 359obs uga

edycji u ytkownika, 589komunikatów, 212, 365,

366, 380modelu zapyta , 200odmiennych klientów,

588powiadomie , 545unikatowej to samo ci

Agregatu, 286wspó bie no ci, 415

dania, 123obszary zainteresowania

aplikacji, 581Oddzielne Drogi, 142

wyj cie us ugi, 599






SKO ROWI DZ 667

odkrywanie, 436Encji, 248, 249ról i obowi zków, 258

odpowiedzialno , 546, 551Odroczona Walidacja, 269odtworzenie stanu

Warto ci, 280odtwórca roli, 259odwzorowanie

Hibernate, 313kolekcji, 313Obiektu Warto ci, 312

ograniczeniemodyfikowania, 419

operacja idempotentna, 393opó nienia, 369oprogramowanie jako

us uga, SaaS, 412optymistyczna

wspó bie no , 452opublikowanie, 199

Zdarzenia Dziedziny,274, 354

BacklogItemCommitted, 431

Oracle Coherence, 488ORM, 310, 319, 320OSIV, Open Session In

View, 586

Ppaczka, bundle, 400pakiet OSGi, 120pami , 441partnerstwo, 141Person, 256perspektywa tabeli bazy

danych, 196plik Tenant.java, 253pliki

BLOB, 639JAR, 120

pobieranie powiadomie ,550

Poddziedzina, 79, 90, 103,519

Generyczna, 79, 98,105, 580

Katalog, 94Pomocnicza, 53, 80, 98,

108, 580Prognozy, 94Zakupy, 107

podejmowanie decyzji, 446podmodu y, 407Podstawowa To samo ,

256podwójna ekspedycja, 428Pojedyncza

Odpowiedzialno , 331pojedyncze Obiekty

Warto ci, 310POJO, Plain Old Java

Object, 59Polecenie, Command, 594

cat, 203grep, 203wc, 204

ponowna analiza projektu,436

Porty i Adaptery, 176, 178posta zdenormalizowana,

309Potok przetwarzania, 207Potoki i Filtry, 203, 204powiadomienie,

notification, 391pozycja magazynowa, 95pozyskiwanie informacji,

436prawo Demeter, 449prefiks get, 305priorytet biznesowy, 299Proces

D ugotrwa y, 208, 212,551

oblicze , 338procesor

polece , 196zapyta , 193

procesy zaawansowane, 573produkt

jako Agregat, 414ProjectOvation, 156

projekt, 63, 102alternatywny, 442

projektowanieEncji, 229idempotentnego obiektu

stanu, 213Modu ów, 398, 399Procesów

D ugotrwa ych, 209strategiczne, 99, 100Us ugi, 329z u yciem Modu ów,

398zaawansowanych

procesów, 573przekazywanie, 260

komunikatów, 539prze czenie fail-over, 221przestrzeganie regu , 436przeszukiwanie

Repozytorium, 604przetwarzanie

polece , 196Potoków i Filtrów, 205rozproszone, 219, 223równoleg e, 209

przyczyny anemii, 57przydzielanie

odpowiedzialno ci, 546przypadek u ycia, 423, 587Publikator Zdarze

Dziedziny, 172, 601publikowanie

obiektówNotificationLog, 383

powiadomie , 375middleware, 380powiadomie bazuj cych

na komunikatach,387

powiadomieo Zdarzeniach, 376

wewn trznego stanuAgregatu, 584

wielokana owe, 389Zdarze , 359, 382Zdarze Dziedziny, 370

Publikuj-Subskrybuj, 359,365, 520






668 SKO ROWI DZ

Rrachunek, 110rdze

Agregatu, 458Oddzielony, 125, 146

refaktoryzacja, 82, 124, 299handlera, 355

referencje, 426regu a DIP, 175regu y, 433

projektowaniaModu ów, 398

rejestr, 377powiadomie , 379

relacje, 137organizacyjne, 140

relacyjna baza danych, 637renderowanie

Agregatów, 585Obiektów Dziedziny,

583obiektów transferu

danych, 583widoku danych, 500

replikacjadanych, 220Zdarzenia, 619

Repozytoria, 124, 235, 469typu kolekcja, 470typu trwa y magazyn, 486

RepozytoriumTopLink, 485zapytania, 587

reprezentacje stanuegzemplarzy Agregatu,587

Resolwer Zale no ciDziedziny, 587

REST, RepresentationalState Transfer, 185,189, 190

RESTful, 115, 179, 186,375, 408, 530

RIA, Rich InternetApplications, 582

rodzaje Poddziedzin, 98

rola, 258IAddOrdersToCustomer,

261IMakeCustomerPreferre

d, 261Person, 259System, 259User, 259

rozbicie Agregatu, 415Roz czony Model

Dziedziny, 426rozmiar Kontekstów

Ograniczonych, 116rozpowszechnianie

wiadomo ci, 365Rozproszona Pami

Podr czna, 201rozsy anie, 260

komunikatów, 375Zdarzenia, 362

rozwi zywanie konfliktówZdarze , 628

rozwijanieoprogramowania, 52

równo Warto ci, 286równowa enie obci enia,

622RPC, Remote Procedure

Calls, 327, 367, 520rywalizacja o dost p, 424Rzutowanie Odczytów

Modelu, 642, 644

SSaaS, Software as a Service,

84, 412Saga, 208Scenariusz

Transakcji, 603u ycia, 439

schizofrenia obiektowa, 260Scrum, 130SEC, Securities and

Exchange Commission,111

Separacja Polece odZapyta , 287

serializacjaJSON, 374specjalistyczna, 488

serializatorDataContractSerializer,

648JsonSerializer, 648Zdarze , 647

serwer HTTP typuRESTful, 187

Sesja, 470setter, 59Siatka, 201

danych Coherence, 487skalowalno , 429sk adnia lambda, 625Skrypt Transakcji, 59, 510s uchacz powiadomie ,

543, 558ExclusiveDiscussion

CreationListener,560

ProductDiscussionRetryListener, 566

SOA, Service-OrientedArchitecture, 181, 327

specyfikacja, 269, 653JavaBean, 305

spo eczno DDD, 102spójno

infrastruktury obs ugikomunikatów, 366

ostateczna, 429implementacja, 443

transakcyjna, 418stabilno to samo ci, 246Stan, 158, 509

typu CurrencyType, 297A+ES, 611Agregatu, 352, 584,

587, 617Procesu, 212, 563REQUESTED, 554

standard Java-Bean, 58statyczne tworzenie

egzemplarzy, 298






SKO ROWI DZ 669

stosowanieDDD, 49, 63, 73Rzutów, 642Wstrzykiwania

Zale no ci, 337Strategia, 269, 302straty magazynowe, 96stra nik, 266Strumie

Zdarze Agregatu, 628,631, 638

Zdarze Dziedziny, 611styl

architektoniczny, 163EDA, 202mechanizmów

utrwalania, 487REST, 185, 375, 587

Subskrybenci, 363subskrybent zdarzenia, 199subskrypcja, 363Subversion, 215system, 580

Coherence, 488, 490e-Commerce, 95kontroli wersji, 215Lokad, 93Magazyn, 96Oracle WebLogic, 605Prognozowania, 105ProjectOvation, 131RabbitMQ, 542RPC, 152

systemyCRUD, 228N-warstwowe, 170rozproszone, 521tradycyjne, legacy

systems, 215szacowanie kosztu

Agregatu, 438szeregowanie cykliczne, 623szeroko kolumny, 313Sze ciok ty, 119szyfrowanie, 331

has a, 332

cis a ArchitekturaWarstw, 171

ledzenieb dów, 371limitu czasu, 563zmian stanu Encji, 274

rodowisko CLR, 120

Ttabela MySQL, 319technika Powiedz, nie

pytaj, 449technologia

ActiveX, 58Agile, 82HATEOAS, 149JAX-RS, 180

Tenant, 253test, 82

jednostkowy, 653testowanie

niezmienno ci, 300Obiektów Warto ci, 298Repozytoriów, 511Us ug, 341z wykorzystaniem

implementacjiw pami ci, 514

zapisu, 513timer TimerMBean, 392tolerancje opó nie , 369TopLink


towaropuszczaj cy magazyn, 96zarezerwowany, 95

towary, commodities, 111to samo , 357

zast pcza, 243transakcje, 364, 501

globalne, 435transfer danych, 583Transformator Danych, 588

translatorCollaboratorTranslator,536

tranzycja liczby godzin, 453tropiciel, 211trwa y magazyn, 486tryb Klient – Dostawca, 141tworzenie

egzemplarzy Encji, 265egzemplarzy obiektów

CalendarEntry, 460egzemplarzy obiektu

Discussion, 463Encji G ównej, 447obiektu ledz cego, 565projektu

oprogramowania,71

Repozytorium, 476Systemu e-Commerce, 95to samo ci zast pczej,

243typu Warto ci, 279Zdarze , 350

TypBazowy Warstwy, 244,

315, 447, 507enum, 295kolekcja, 470ProjectId, 649Serializable, 303trwa y magazyn, 470wyliczeniowy, 321

typyAgregatów, 39niestandardowe, 314standardowe, 111, 158,

292, 294Wzmocnione, 293

Uukierunkowana na

komunikaty warstwmiddleware, 327

UML, Unified ModelingLanguage, 66

unikanieodpowiedzialno ci, 551






670 SKO ROWI DZ

unikatowa to samo , 229uprawnienia, 101User, 253Us uga, 73, 116, 325

AccessService, 532Aplikacji, 59, 67, 126,

327, 340, 417, 552,592

dost p do Agregatu, 614implementacja, 613wzorzec A+ES, 613

biznesowa, 580Dziedziny, 40, 124, 290,

297, 327, 340, 500,613

MemberService, 155, 405Otwartego Hosta, 115,

143 159, 171, 465,534

ProductService, 564TeamService, 545

us ugiREST, 155transformacji, 341

utrwalanie, 637Encji, 241, 242kolekcji egzemplarzy

Warto ci, 314Magazynu Zdarze , 392obiektów BLOB, 639Obiektów Warto ci, 308obiektu, 241

uwierzytelnianie, 329,335, 342

uzasadnienie dlamodelowaniadziedziny, 78

U ytkownicy systemu, 255U ytkownik, User, 101, 256u ywanie

Magazynu Zdarze , 372Mediatora, 584

Wwalidacja, 265

atrybutów, 266ca ych obiektów, 269Encji, 272kompozycji obiektów, 273

walidator wielokrotnegou ytku, 270

Warstwa, 119, 170Aplikacji, 57, 408Infrastruktury, 170, 604Interfejsu U ytkownika,

295, 408, 502middleware, 375, 380Us ug, 57Zapobiegaj ca

Uszkodzeniom, 141,150–154, 291, 381,405, 465, 533

Warstwy InterfejsuU ytkownikai Aplikacji, 170

warto cibiznesowe, 50, 69, 184denormalizowane, 313serializowane, 313

WartoCa a, 281, 285MonetaryValue, 293niezmienialna, 279null, 268, 335

wartownik, 246w tki rywalizuj ce, 627WebLogic, 605widok, 590

ArchivedProjectsPerCustomerinterakcji, 362Modelu Odczytu, 646View, 646

Wielka Kula B ota, 101,137, 142

Wielokrotnewykorzystywanie, 182

wizualne narz dziaprogramowania, 58

w a ciciel produktu, 540w a ciwo ci

Encji, 249klasy, 651Zdarze , 351

w a ciwodiscussion, 562eventBody, 374

wpis, entry, 487

wsparcie spójno ciostatecznej, 430

wspólne dzia anieAgregatów, 426

wspó bie no , 626Wspó dzielone J dro, 114,

190Wstrzykiwanie Zale no ci,

176, 337, 454, 604Wtyczki, 176Wyciekanie Modelu

Danych, 309wydajno , 630

Agregatów A+ES, 633zapyta , 435

Wydawca, 359Wydzielony Interfejs, 305,

333, 382wygodny

interfejs u ytkownika,433

system, 71wyj tek

AuthenticationFailedException, 344

EventStoreConcurrencyException, 627

IllegalArgumentException, 308

wyj tki frameworkaHibernate, 481

wykres sekwencji, 372Wykrywalno , 182wymagania funkcjonalne,

179wymienianie informacji, 522wysokopoziomowe wzorce

projektowania, 147wysy anie

wielokrotnekomunikatu, 393

zmagazynowanych Zdarze , 375

wyszukiwanieegzemplarzy, 513egzemplarzy obiektu

Product, 493identyfikatora, 240podstawowych

zachowa , 253






SKO ROWI DZ 671

wzbogacanie Zdarze , 645wzorce

architektoniczne, 163implementacji, 655pomocnicze, 647

wzorzecA+ES, 612, 630, 655Agregat, 429Aktywny Rekord, 510Architektury

Warstwowej, 170Brama do Danych

Tabeli, 510Budowniczy, 457Checks, 269CQRS, 193, 588DAO, 510D ugotrwa e Procesy, 563Fabryka, 457Fabryka Abstrakcyjna,

457Interfejsu Ujawniaj cego

Zamiar, 254Kometa, 201Magazynowanie

Zdarze , 216, 350Maper Danych, 510Mapowania Kontekstu,

120Metoda Fabrykuj ca, 457Modu Tabeli, 510Polecenie, 223, 594projektowy Obserwator,

198Publikuj-Subskrybuj, 365separacji polecenie-

zapytanie, CQS, 191Skrypt Transakcji, 510Specyfikacja, 269Stan, 295, 296Strategia, 269Typ Bazowy Warstwy,

244Us uga Aplikacji, 67Warto Ca a, 281

róde Zdarze , 217

YYAGNI, 584

ZZachowania Pozbawione

Skutków Ubocznych,279, 287

zapis z opó nieniem, 620zapiski na tablicy, 78, 98,

106, 108, 113, 116,118, 147, 151, 246,356, 381, 419, 431

zapytaniaCQS, 417do Repozytorium, 587

zapytanie o identyfikator,242

zarchiwizowany rejestr, 377zarz dzanie

odst pami czasu, 391projektem, 85

Agile, 130, 140Scrum, 130

spójno ci , 419transakcjami, 501wspó bie no ci , 626

zasadaDRY, 49Odwracania Zale no ci,

174, 333, 336, 479Odwracania Zale no ci,

DIP, 581podstawienia Liskov,

LSP, 507zasady

dotycz ceRepozytoriów, 472

projektowe us ug, 182zasi g J zyka

Wszechobecnego, 68zasoby RESTful, 376, 408,

530zast pczy identyfikator

to samo ci, 245, 316zast powalno , 284zastosowanie

Agregatów, 412

DDD, 44Encji, 227stra ników, 266stylu EDA, 202

za lepka, mock, 342zbiór interfejsów SOAP, 183zdalne wywo ania

procedur, RPC, 327,367, 520

Zdarzenia, 116, 524Dziedziny, 40, 73, 129,

155, 172, 198, 202,208, 211, 347, 429,601, 647

niemutowalne, 353z cechami Agregatu, 356

zdarzenieAllPhoneNumbers

Counted, 210AllPhoneNumbersListed,

206BacklogItemCommitted,

361, 364, 431DiscussionRequest

Failed, 568DiscussionStarted, 560,

569MatchedPhone

NumbersCounted,206

PersonContactInformationChanged, 549

PersonNameChanged,549

ProductCreated, 559ProductDiscussionReque

stTimedOut, 567ProjectArchived, 646UserAssignedToRole,

541, 544zdenormalizowany model

danych, 194zintegrowane rodowisko

programisty, IDE, 58Z agodzona Architektura

Warstw, 171z czenia tabel, 319

theta joins, 428






672 SKO ROWI DZ

z o ono dziedziny, 53z o ony typ Warto ci, 285znaczenie Map Kontekstu,

136znacznik czasu, 352

occurredOn, 390

zserializowanewywo anie metody, 598Zdarzenia, 371, 376

zu ycie pami ci, 441ród a Zdarze , 349, 611

danie GET, 537






http://program-partnerski.helion.pl

Documents

Tytuł oryginału: Implementing Domain-Driven Designpdf.helion.pl/dddaro/dddaro.pdf · Mimo to możemy sięgnąć wyżej — po dobrze zaprojektowany model oprogra-mowania, który