Tytuł oryginału: Domain-Driven Design: Tackling Complexity ... · kowaÊ przez sieci komputerowe,...

Tytuł oryginału: Domain-Driven Design: Tackling Complexity in the Heart of Software

Tłumaczenie: Rafał SzpotonProjekt okładki: Studio Gravite / OlsztynObarek, Pokoński, Pazdrijowski, Zaprucki

ISBN: 978-83-283-0525-0

Authorized translation from the English language edition, entitled: DOMAIN-DRIVEN DESIGN: TACKLING COMPLEXITY IN THE HEART OF SOFTWARE; ISBN 0321125215; by Eric Evans; published by Pearson Education, Inc, publishing as Addison Wesley.Copyright © 2004 by Eric Evans.

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 © 2015.

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.

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

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)

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

Drogi Czytelniku!Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/domdriMoż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/domdri

http://helion.pl/rf/domdri

http://helion.pl/ro/domdri

http://helion.pl

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

7

SPIS TRE CI

Przedmowa ...................................................................................... 15Wst p .............................................................................................. 17Podzi kowania ................................................................................. 27

Cz IZastosowanie modelu dziedziny ..........................29

Rozdzia 1. Przetwarzanie wiedzy ................................................... 35

Elementy wydajnego modelowania ................................................40Przetwarzanie wiedzy ......................................................................41Ci g a nauka .....................................................................................44Projekt bogaty w wiedz .................................................................45Modele dog bne .............................................................................48

Rozdzia 2. Komunikacja i u ycie j zyka ......................................... 51

J zyk wszechobecny ........................................................................52Modelowanie na g os .......................................................................58Jeden zespó , jeden j zyk .................................................................60Dokumenty i diagramy ...................................................................63

Spisane dokumenty projektowe ....................................................65Wykonywalna podstawa .............................................................68

Modele obja niaj ce .........................................................................68

Rozdzia 3. Zwi zanie modelu z implementacj ............................... 71

Projektowanie sterowane modelem ...............................................73Paradygmaty modelowania i narz dzia wspieraj ce ......................76

Projekt mechaniczny ...................................................................79Projekt sterowany modelem .........................................................80

Odkrywanie szkieletu — dlaczego modele s wa nedla u ytkowników .........................................................................83

Modelowanie praktyczne ................................................................86

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



8 SPIS TRE CI

Cz IIElementy sk adowe projektusterowanego modelem .......................................... 89

Rozdzia 4. Wyizolowanie dziedziny ...............................................93

Architektura warstwowa ................................................................. 94Powi zanie warstw .................................................................... 99Szkielety architektury ............................................................... 100

To w warstwie dziedziny yje model ........................................... 101Antywzorzec inteligentnego interfejsu u ytkownika .................. 102Inne rodzaje izolacji ...................................................................... 106

Rozdzia 5. Wyra enie modelu w programie ...................................107

Asocjacje ........................................................................................ 109ENCJE (zwane równie obiektami referencyjnymi) .................. 115

Modelowanie ENCJI .............................................................. 120Projektowanie operacji na to samo ci ......................................... 121

WARTO CI .................................................................................. 125Projektowanie OBIEKTÓW WARTO CI ............................ 128Projektowanie asocjacji korzystaj cych z WARTO CI .............. 131

US UGI ........................................................................................ 132US UGI a wyizolowana warstwa dziedziny .......................... 134Ziarnisto ............................................................................... 136Dost p do US UG ................................................................. 137

MODU Y (zwane równie PAKIETAMI) ................................ 138MODU Y zwinne (agile modules) ......................................... 140Pu apki tworzenia pakietów na podstawie wymogów

infrastruktury ........................................................................ 142Paradygmaty modelowania ........................................................... 146

Dlaczego dominuje paradygmat obiektowy? ............................... 146Nieobiekty w wiecie obiektowym .............................................. 149Utrzymywanie PROJEKTU STEROWANEGO

MODELEM w przypadku czenia paradygmatów .............. 150

Rozdzia 6. Cykl ycia obiektu dziedziny .......................................153

AGREGATY .................................................................................. 155FABRYKI ....................................................................................... 166

Wybór FABRYK oraz ich miejsc .............................................. 169Kiedy potrzebujesz jedynie konstruktora .................................... 171Projektowanie interfejsu ............................................................ 173




SPIS TRE CI 9

Gdzie mie ci si logika niezmienników? ....................................174FABRYKI ENCJI a FABRYKI WARTO CI ......................174Odtwarzanie zachowanych obiektów .........................................175

REPOZYTORIA ...........................................................................178Odpytywanie REPOZYTORIUM .........................................184Kod klienta, w przeciwie stwie do programistów,

ignoruje implementacj REPOZYTORIUM .........................185Implementacja REPOZYTORIUM ........................................186Praca ze szkieletami architektury ...............................................188Relacje z FABRYKAMI ..........................................................189

Projektowanie obiektów dla relacyjnych baz danych ..................190

Rozdzia 7. U ycie j zyka — przyk ad rozszerzony ....................... 195

Prezentacja systemu logistycznego dla adunku ..........................195Izolowanie dziedziny — wprowadzenie aplikacji ........................198Rozró nianie ENCJI oraz WARTO CI ......................................199

Role (rola) oraz inne atrybuty ....................................................201Projektowanie asocjacji w dziedzinie logistyki morskiej .............201Granice AGREGATU ...................................................................203Wybór REPOZYTORIÓW ..........................................................204Przegl danie scenariuszy ...............................................................206

Przyk adowa funkcjonalno aplikacji — zmiana miejscaprzeznaczenia adunku ..........................................................206

Przyk adowa funkcjonalno aplikacji — powtórzenie operacji ....206Tworzenie obiektów .....................................................................207

FABRYKI oraz konstruktory klasy Cargo .................................207Dodanie operacji obs ugi ............................................................208

Przerwa na refaktoring — projekt alternatywnyAGREGATU Cargo ...................................................................209

MODU Y w modelu logistyki morskiej .....................................213Nowa funkcjonalno — sprawdzanie przydzia u ......................215

czenie dwóch systemów .........................................................216Wzbogacanie modelu — segmentacja biznesu .............................217Poprawa wydajno ci .................................................................219

Ostateczna wersja ..........................................................................220




10 SPIS TRE CI

Cz IIIRefaktoryzacja ku g bszemu zrozumieniu ....... 223

Rozdzia 8. Moment prze omowy ...................................................229

Historia pewnego prze omu ......................................................... 230Przyzwoity model, lecz wci ... ................................................ 230Moment prze omowy ................................................................ 231Model pog biony ..................................................................... 233Otrze wiaj ca decyzja .............................................................. 236Zap ata ................................................................................... 237

Mo liwo ci .................................................................................... 237Koncentracja na podstawach ......................................................... 237Epilog — potok nowych spostrze e ........................................... 238

Rozdzia 9. Odkrywanie poj niejawnych ......................................241

Wyci ganie poj ........................................................................... 242Nas uchiwanie j zyka .............................................................. 242Analiza dziwnej implementacji ................................................. 247Rozmy lanie nad sprzeczno ciami ............................................. 252Czytanie ksi ki ...................................................................... 253Wielokrotne powtarzanie prób .................................................. 255

W jaki sposób zamodelowa mniej oczywiste poj cia ................. 256Procesy jako obiekty dziedziny .................................................. 259SPECYFIKACJA .................................................................. 261Zastosowanie SPECYFIKACJI w implementacji ..................... 264

Rozdzia 10. Projekt elastyczny ......................................................279

INTERFEJSY UJAWNIAJ CE ZAMIAR ................................. 283FUNKCJE BEZ EFEKTÓW UBOCZNYCH ......................... 287ASERCJE ....................................................................................... 293

Teraz widzimy lepiej ............................................................... 296ZARYSY KONCEPCYJNE ......................................................... 298

Nieprzewidziana zmiana ......................................................... 301KLASY SAMODZIELNE ............................................................ 304ZAMKNI CIE OPERACJI ......................................................... 307Projektowanie deklaratywne ......................................................... 310

J zyki w a ciwe dziedzinie ....................................................... 311Deklaratywny styl projektowania ................................................. 312

Rozszerzenie SPECYFIKACJI w stylu deklaratywnym ........... 313Subsumpcja ............................................................................. 318




SPIS TRE CI 11

Kierunki ataku ................................................................................321Definiowanie poddziedzin ........................................................321W miar mo liwo ci polegaj na ustalonym formalizmie ...............322

Rozdzia 11. Stosowanie wzorców analitycznych ............................ 333

Rozdzia 12. Powi zanie wzorców projektowych z modelem ........... 349

STRATEGIA (zwana równie POLITYK ) ...............................351KOMPOZYT ................................................................................356Dlaczego nie wzorzec PY KU (FLYWEIGHT)? ........................361

Rozdzia 13. Refaktoryzacja ku g bszemu zrozumieniu ................. 363

Pocz tek .........................................................................................364Zespo y poszukiwawcze ................................................................364Wcze niejsze odkrycia ...................................................................365Projekt dla programistów ..............................................................366Wyczucie czasu ..............................................................................367Kryzys jako ród o mo liwo ci .....................................................368

Cz IVProjekt strategiczny .............................................369

Rozdzia 14. Utrzymywanie integralno ci modelu ........................... 373

KONTEKST ZWI ZANY ..........................................................377Rozpoznawanie odprysków poj ciowych

w KONTEK CIE ZWI ZANYM ...................................381CI G A INTEGRACJA ..............................................................383MAPA KONTEKSTÓW .............................................................386

Testowanie na granicach KONTEKSTU ................................393Organizacja oraz dokumentacja MAP KONTEKSTÓW ........394

Relacje pomi dzy KONTEKSTAMI ZWI ZANYMI ..............395J DRO WSPÓ DZIELONE ......................................................396ZESPO Y PROGRAMISTYCZNE

KLIENTA – DOSTAWCY ........................................................398KONFORMISTA .........................................................................403WARSTWA ZAPOBIEGAJ CA USZKODZENIU ................406

Projektowanie interfejsu WARSTWY ZAPOBIEGAJ CEJUSZKODZENIU .............................................................408

Implementacja WARSTWY ZAPOBIEGAJ CEJUSZKODZENIU .............................................................408

Opowie ku przestrodze ...........................................................412




12 SPIS TRE CI

ODDZIELNE DROGI ................................................................ 414US UGA OTWARTEGO GOSPODARZA ............................ 417J ZYK OPUBLIKOWANY ......................................................... 419Unifikacja s onia ............................................................................ 422Wybór strategii kontekstu modelu ............................................... 426

Decyzja zespo owa lub wy sza ................................................. 426Stawianie siebie w kontek cie .................................................... 427Przekszta canie granic .............................................................. 427Akceptacja tego, czego nie mo emy zmieni

— wyznaczanie zewn trznych systemów ................................ 428Relacje z systemami zewn trznymi ............................................ 429System w projektowaniu ........................................................... 430Dostosowanie do specjalnych potrzeb przy u yciu

odr bnych modeli ................................................................... 431Wdro enie ............................................................................... 432Kompromis .............................................................................. 433Kiedy projekt ju trwa .............................................................. 433

Transformacje ............................................................................... 434czenie KONTEKSTÓW — ODDZIELNE DROGI

J DRO WSPÓ DZIELONE .......................................... 434czenie KONTEKSTÓW — J DRO

WSPÓ DZIELONE CI G A INTEGRACJA ....... 437Wygaszanie starego systemu ...................................................... 438US UGA OTWARTEGO GOSPODARZA

J ZYK OPUBLIKOWANY ............................................. 440

Rozdzia 15. Destylacja ..................................................................443

DZIEDZINA G ÓWNA ............................................................ 446Wybór RDZENIA dziedziny .................................................. 449Kto wykonuje prace? ................................................................ 449

Zwi kszanie destylacji ................................................................... 451PODDZIEDZINY OGÓLNE .................................................... 452

Ogólny nie oznacza mo liwy do ponownego wykorzystania ....... 459Zarz dzanie ryzykiem projektowym ......................................... 459

OPIS WIZJI DZIEDZINY .......................................................... 461RDZE WYRÓ NIONY .......................................................... 464

Dokument destylacji ................................................................. 465RDZE oznaczony ................................................................ 466Dokument destylacji jako narz dzie procesowe ........................... 467




SPIS TRE CI 13

SPÓJNE MECHANIZMY ..........................................................469OGÓLNE PODDZIEDZINY

a SPÓJNE MECHANIZMY ............................................471Kiedy MECHANIZM jest cz ci

DZIEDZINY G ÓWNEJ ................................................472Destylacja do stylu deklaratywnego ..............................................473RDZE ODDZIELONY ............................................................474

Koszt utworzenia RDZENIA ODDZIELONEGO ..............475Rozwijanie decyzji zespo owych ................................................476

RDZE ABSTRAKCYJNY .........................................................481G boka destylacja modelu ...........................................................482Wybór celów refaktoryzacji ...........................................................483

Rozdzia 16. Struktury du ej skali ................................................. 485

PORZ DEK EWOLUCYJNY ....................................................490METAFORA SYSTEMU .............................................................493

Dlaczego nie potrzebujemy metafory „naiwnej” ..........................495WARSTWY ODPOWIEDZIALNO CI .....................................496

W jaki sposób struktura wp ywa na bie cy projekt? ...................502Wybór odpowiednich warstw .....................................................505

POZIOM WIEDZY ......................................................................511SZKIELET KOMPONENTÓW DO CZANYCH ..............521Jak ograniczaj ca powinna by struktura? ....................................526Refaktoryzacja ku lepiej dopasowanej strukturze ........................527

Minimalizm ............................................................................528Komunikacja oraz samodyscyplina .............................................528Restrukturyzacja przyczynia si do projektu elastycznego .............529Destylacja zmniejsza obci enie ................................................530

Rozdzia 17. czenie strategii ....................................................... 531

czenie struktur du ej skaliz KONTEKSTAMI ZWI ZANYMI .......................................531czenie struktur du ej skali oraz destylacji ................................534

Najpierw oszacowanie ...................................................................536Kto okre la strategi ? .....................................................................536

Powstawanie struktury w trakcie tworzenia aplikacji ..................537Zespó architektoniczny skoncentrowany na kliencie ....................538

Sze podstawowych kryteriów dotycz cych podejmowaniastrategicznych decyzji projektowych .........................................538

To samo dotyczy szkieletów technicznych ...................................541Wystrzegaj si planu g ównego ...................................................542




14 SPIS TRE CI

Zako czenie ........................................................ 545Dodatek ..........................................................................................553Wykorzystanie szablonów z tej ksi ki ............................................553S ownik .........................................................................................559Bibliografia .....................................................................................565Prawa do zdj ................................................................................567Skorowidz ......................................................................................569




93

ROZDZIA 4.

Wyizolowaniedziedziny

ragment oprogramowania, który adresuje g ówne problemy dzie-dziny, stanowi najcz ciej tylko ma cz ca ego systemu informatycznego.Niemniej jednak jego znaczenie jest nieproporcjonalne w stosunku dorozmiaru. Aby móc zastosowa nasze najlepsze pomys y, musimy byw stanie dostrzec w poszczególnych elementach modelu ca y system.Nie mo emy by zmuszeni do wybierania ich z wi kszego zestawu obiek-tów, tak jak gwiazdozbiorów na nocnym niebie. Musimy oddzieli obiektydziedziny od innych funkcji systemu, aby nie miesza poj dziedzinowychz innymi, zwi zanymi jedynie z technologi oprogramowania. W g szczuca ego systemu nie mo emy te straci z oczu samej dziedziny.

W tym celu powsta y zaawansowane techniki s u ce do wyizolo-wania dziedziny. To dobrze znany obszar, lecz jest on tak istotny w prawi-d owym zastosowaniu pryncypiów modelowania dziedzinowego, e musizosta w tym miejscu krótko omówiony z punktu widzenia projektowaniasterowanego dziedzin .

F




94 ROZDZIA 4. WYIZOLOWANIE DZIEDZINY

Architektura warstwowa

W przypadku prostej aplikacji wspieraj cej u ytkownika w procesie wyborumiejsca przeznaczenia dla adunku z listy dost pnych miast musi istniekod programu, który (1) rysuje element interfejsu u ytkownika na ekranie,(2) zadaje pytanie do bazy danych w celu uzyskania listy wszystkich mo -liwych miast, (3) odczytuje wybór u ytkownika i go sprawdza, (4) przy-pisuje wybrane miasto do adunku oraz (5) zapisuje wybór do bazy da-nych. Ca y ten kod nale y do jednego programu, lecz tylko jego ma acz jest zwi zana z dziedzin logistyki morskiej.

Programy wymagaj od projektu oraz kodu, aby obs ugiwa y wieleró nych rodzajów zada . Musz przecie pobiera dane od u ytkownika,wykonywa logik biznesow , odwo ywa si do bazy danych, komuni-kowa przez sieci komputerowe, wy wietla informacje dla u ytkownikai tak dalej. Z tej przyczyny ilo kodu odpowiedzialnego za ka d funk-cjonalno programu mo e by znaczna.

W programowaniu obiektowym kod obs uguj cy interfejsu ytkownika, baz danych, a tak e wykonuj cy inne czynno cipomocnicze jest bardzo cz sto umieszczany bezpo rednio w obiek-tach biznesowych. Dodatkowa logika biznesowa jest równie




ARCHITEKTURA WARSTWOWA 95

umieszczona w kodzie interfejsów u ytkownika oraz skryptachbazodanowych. Dzieje si tak dlatego, i w krótkiej perspektywiejest to najprostszy sposób na utworzenie dzia aj cego kodu.

W sytuacji, gdy kod zwi zany z dziedzin jest rozproszonyw tak du ej ilo ci innego kodu, niezmiernie trudno jest go dojrzei zrozumie . Pobie ne zmiany do interfejsu u ytkownika mogw rzeczywisto ci zmieni logik biznesow . A zmiana regu y biz-nesowej mo e wymaga skrupulatnego ledzenia kodu obs uguj -cego interfejs u ytkownika, baz danych lub inne elementy pro-gramu. Implementacja spójnych obiektów sterowanych modelemstaje si niepraktyczna, a testowanie automatyczne jest niewy-godne. Z powodu wszystkich tych technologii i logiki zaanga o-wanych w ka d czynno program musi albo by bardzo prosty,albo te stanie si praktycznie niemo liwy do zrozumienia.

Tworzenie programów obs uguj cych bardzo z o one zadania wymagarozdzielenia zagadnie , umo liwiaj c tym samym samodzielne i wy czneskupienie si na ró nych cz ciach projektu. W tym samym czasie z o oneinterakcje w systemie musz by przeprowadzane z my l o utrzymaniutej roz czno ci.

Istnieje wiele sposobów podzia u systemu informatycznego, jednakdo wiadczenie przemys owe pozwoli o utworzy i zdefiniowa ARCHI-TEKTURY WARSTWOWE, sk adaj ce si w szczególno ci z kilku ca kiemstandardowych warstw. Metafora podzia u systemu na warstwy jest takpowszechnie stosowana, e dla wi kszo ci programistów wydaje si intu-icyjna. W literaturze dost pnych jest wiele dobrych dyskusji na tematpodzia u systemów na warstwy. Niektóre z nich s nawet uj te w postaciwzorców (jak w ksi ce Buschmana1 z roku 1996 — strony 31 – 51).Podstawowa zasada stanowi, e dowolny element w danej warstwie jestzale ny jedynie od innych elementów w tej samej warstwie lub w war-stwach ni szych. Komunikacja w gór musi przechodzi przez mechanizmpo redni, który zostanie omówiony nieco pó niej.

Podstawow warto ci warstw jest fakt, i ka da z nich specjalizujesi w konkretnym aspekcie programu komputerowego. Ta specjalizacjaumo liwia utworzenie bardziej spójnych projektów ka dego z nich, a coza tym idzie, projekty te s prostsze w interpretacji. Oczywi cie, niezmier-nie istotne jest wybieranie warstw, które b d zawiera najbardziej spójnei wa ne aspekty projektu. Z pomoc ponownie przychodz do wiadczenie

1 Frank Buschman jest wspó autorem ksi ki Pattern-Oriented Software Archi-

tecture, opisuj cej szczegó owo zastosowanie wzorców w projektowaniu archi-tektury — przyp. t um.





oraz konwencje przemys owe. Chocia istnieje wiele typów warstw, tojednak najbardziej skuteczne architektury u ywaj pewnych odmian nast -puj cych czterech warstw poj ciowych:

Warstwa interfejsuu ytkownika(lub prezentacji)

Odpowiedzialna za wy wietlanie informacjidla u ytkownika oraz interpretacj jego polece .Zamiast u ytkownika zewn trzny aktor mo e byniekiedy innym systemem komputerowym.

Warstwa aplikacji Definiuje zamierzone zadania programu i sterujeobiektami dziedziny w celu rozwi zania postawionychprzed nimi zada . Zadania, za które jest odpowiedzialnata warstwa, s znacz ce dla biznesu i wymagane w celupoprawnego wspó dzia ania z warstwami aplikacjiinnych systemów. Warstwa jest utrzymywanaw zwi z ej postaci. Nie zawiera regu ani wiedzybiznesowej, a jedynie zarz dza zadaniami i deleguje jedo rozwi zania przez obiekty dziedzinowe w kolejnejwarstwie ni ej. Warstwa nie musi odzwierciedlakonkretnej sytuacji biznesowej, lecz mo e posiadastan, ukazuj cy post p zadania u ytkownikowilub programowi.

Warstwa dziedziny(lub modelu)

Warstwa odpowiedzialna za reprezentacj zagadniebiznesowych, informacji o sytuacji biznesowej orazregu biznesowych. W tym miejscu jest przechowywanyoraz u ywany stan odzwierciedlaj cy sytuacjbiznesow , chocia szczegó y techniczne zwi zanez przechowywaniem tego stanu s oddelegowanedo warstwy infrastruktury. Ta warstwa stanowi istotprogramu od strony biznesowej.

Warstwainfrastruktury

Udost pnia podstawowe mo liwo ci technicznewspieraj ce warstwy wy sze, tj. komunikaty wysy anedo aplikacji, zachowywanie dziedziny, rysowanieelementów interfejsu u ytkownika itp. Warstwainfrastruktury mo e równie poprzez szkieletarchitektury wspiera wzorzec interakcji pomi dzywszystkimi czterema warstwami.

Niektóre projekty nie tworz ostrego podzia u pomi dzy warstwamiinterfejsu u ytkownika oraz aplikacji. Inne maj wiele warstw infrastruk-tury. Jednak to w a nie wydzielenie warstwy dziedziny jest istotne w celuumo liwienia stosowania PROJEKTU STEROWANEGO MODELEM.





Dlatego:Podziel z o ony program na warstwy. Utwórz projekt ka -

dej z nich, czyni c j zarazem spójn , jak i zale n jedynie odwarstw po o onych ni ej. Aby utrzyma lu ne powi zanie z wy -szymi warstwami, stosuj standardowe wzorce architektoniczne.Umie kod zwi zany z modelem dziedziny w pojedynczej war-stwie i odizoluj go od kodu interfejsu u ytkownika, aplikacji orazinfrastruktury. Dzi ki takiemu podej ciu obiekty dziedziny, pozba-wione konieczno ci obs ugi wy wietlania, przechowywania, zarz -dzania zadaniami aplikacji itd., mog skoncentrowa si jedyniena wyra eniu modelu dziedziny. To umo liwia wzbogaceniei uproszczenie modelu na tyle, aby móg on wychwyci wiedzbiznesow i wykorzysta j w praktyce.

Oddzielenie warstwy dziedziny od warstw infrastruktury oraz inter-fejsu u ytkownika umo liwia utworzenie bardziej przejrzystego projektuka dej z nich. Utrzymanie wyizolowanych warstw jest zdecydowanie mniejkosztowne, poniewa s one rozwijane we w asnym tempie i odpowia-daj na ró ne w asne potrzeby. Podzia na warstwy pomaga równie wewdro eniu systemu rozproszonego, pozwalaj c na umieszczenie poszcze-gólnych warstw na ró nych serwerach oraz klientach w celu zmniejsze-nia narzutu komunikacyjnego i zwi kszenia wydajno ci (Fowler 1996).

Przyk ad

Podzia na warstwy w przypadku funkcjonalno ciinternetowej systemu bankowegoAplikacja udost pnia szereg funkcjonalno ci zarz dzania kontami banko-wymi. Jedn z nich jest przelew rodków, gdzie u ytkownik podaje numerydwóch rachunków oraz kwot , a nast pnie zatwierdza przelew.

Aby ten przyk ad by o atwiej zrozumie , pomin wi kszo tech-nicznych aspektów, a w szczególno ci zabezpieczenia. Projekt dziedzinyzostanie równie uproszczony (rzeczywista z o ono zwi kszy aby jedyniepotrzeb posiadania architektury warstwowej). Co wi cej, ta konkretnainfrastruktura zaprezentowana w tym przyk adzie mia a w zamierzeniuby prosta oraz oczywista, co dotyczy mia o równie samego przyk adu —nie jest to aden sugerowany projekt. Odpowiedzialno ci zwi zane z pozo-sta ymi funkcjonalno ciami systemu b d podzielone na warstwy w sposóbprzedstawiony na rysunku 4.1.

Zauwa , e to warstwa dziedziny, a nie warstwa aplikacji jest odpowie-dzialna za podstawowe regu y biznesowe — w tym przypadku regu a mówi:„Ka de uznanie na rachunku musi mie odpowiadaj ce mu obci enie”.





Rysunek 4.1.Obiekty wype niajodpowiedzialno cizgodne z warstw ,

do której przynale ,i s bardziej

zwi zane z innymiobiektami w tejsamej warstwie

Aplikacja nie czyni adnych za o e co do ród a pochodzenia daniaprzelewu. Interfejs u ytkownika zawiera b dzie prawdopodobnie pola dowprowadzania numerów kont oraz warto ci przelewu, a tak e przyciskiodpowiedzialne za wydawanie polece . Móg by on jednak — bez wp ywuna warstw aplikacji oraz jak kolwiek z ni szych warstw — zosta zast piony

daniem przelewu w postaci dokumentu XML. Takie rozdzielenie warstwwyst puje nie dlatego, e w projektach interfejsy u ytkowników s cz stozast powane dokumentami XML, lecz dlatego, e spójne rozdzielenie zadaczyni projekt ka dej warstwy atwym do zrozumienia i utrzymania.

W rzeczywisto ci sam rysunek 4.1 jedynie w sposób umiarkowanyilustruje problem braku izolacji dziedziny. Poniewa musia on obejmowawszystko, pocz wszy od dania przelewu, do nadzorowania transakcji,warstwa dziedziny musi zosta uproszczona w taki sposób, aby ca a inter-akcja z systemem by a do prosta do zrozumienia. Gdyby my skoncen-trowali si na projekcie wyizolowanej warstwy dziedziny, zostawiliby mymiejsce na stronie oraz w naszych g owach na model, który w lepszysposób reprezentowa by regu y tej dziedziny. By mo e do czyliby mype n rachunkowo , obiekty obci e i uzna rachunków albo te obiektyreprezentuj ce transakcje pieni ne.





Powi zanie warstwJak dot d nasza dyskusja skupia a si na rozdzieleniu warstw oraz na tym,w jaki sposób partycjonowanie ulepsza projekt ka dego aspektu programu,w szczególno ci warstwy dziedziny. Jednak warstwy, oczywi cie, muszby ze sob po czone. Wykonanie takiego po czenia bez utraty korzy ciwynikaj cych z ich rozdzielenia le y u podstaw wielu wzorców.

Warstwy maj by lu no zwi zane, a zale no ci projektowe muszby tylko jednokierunkowe. Warstwy wy sze mog w prosty sposób u ywaelementów warstw ni szych poprzez wykorzystanie ich interfejsów publicz-nych, przechowuj c odwo ania do nich (cho by tymczasowo) — ogólnierzecz bior c, u ywaj c standardowych sposobów komunikacji. Jednak ew przypadku, gdy obiekt warstwy ni szej potrzebuje skomunikowa siw gór (nie mówimy o zwyk ej odpowiedzi na zapytanie), musimy skorzy-sta z innego mechanizmu, u ywaj c w tym celu wzorca architektonicz-nego do czenia warstw w rodzaju odwo a zwrotnych (callbacks) alboOBSERWATORÓW (patrz Gamma 1995 r.).

Dziadkiem wszystkich wzorców u ywanych do czenia interfejsuu ytkownika z warstwami aplikacji oraz dziedziny jest MODEL-WIDOK--KONTROLER (ang. model-view-controler — MVC). Wzorzec ten zostazapocz tkowany w okresie wietno ci Smalltalka w latach 70. ubieg egowieku i zainspirowa wiele pó niejszych architektur interfejsu u ytkow-nika. Wraz ze swoimi wieloma przydatnymi odmianami zosta on omó-wiony przez Fowlera (2003 r.). Równie Larman (1998 r.) sprawdza tentemat we WZORCU ROZDZIELENIA MODELU-WIDOKU, a opra-cowany przez niego KOORDYNATOR APLIKACJI jest jednym z podejstosowanych do po czenia z warstw aplikacji.

Oczywi cie, istniej inne style czenia interfejsu u ytkownika z apli-kacj . Do naszych zastosowa wszystkie z nich b d poprawne, o ile b dzachowywa izolacj warstwy dziedziny, pozwalaj c projektowa obiektydziedziny bez jednoczesnego przejmowania si interfejsem u ytkownika,który móg by ich pó niej u ywa .

Warstwa infrastruktury nie inicjuje zazwyczaj adnych akcji w war-stwie dziedziny. Istniej c „poni ej” warstwy dziedziny, nie powinna onaposiada adnej konkretnej wiedzy o dziedzinie, której s u y. Rzeczywi cietego rodzaju techniczne mo liwo ci s bardzo cz sto udost pniane w cha-rakterze US UG. Je eli na przyk ad aplikacja chce wys a wiadomoe-mail, wtedy w warstwie infrastruktury mo e zosta zlokalizowany inter-fejs s u cy do wysy ania wiadomo ci, za elementy warstwy aplikacjimog yby tylko za da jej wys ania. Tego rodzaju rozdzielenie daje dodat-kow wielofunkcyjno . Interfejs do wysy ania wiadomo ci móg by zosta





po czony z serwerem pocztowym, faksowym lub dowolnym innym aktu-alnie dost pnym. Jednak najwa niejsza korzy zwi zana jest z uprosz-czeniem warstwy aplikacji, która jest w sko skoncentrowana na swoimzadaniu i wie, kiedy ma wys a wiadomo , lecz nie przejmuje si tym,w jaki sposób to wykona .

Warstwy aplikacji oraz dziedziny polegaj na US UGACH dostar-czanych przez warstw infrastruktury. Je eli tylko zakres US UGI zostapoprawnie wybrany, a jej interfejs prawid owo zaprojektowany, wtedyobiekt wywo uj cy mo e pozosta lu no zwi zany, bez uwzgl dnianiaskomplikowanej logiki kryj cej si pod interfejsem US UGI.

Jednak nie ca a infrastruktura przykryta jest US UGAMI mo liwymido wywo ania z warstw wy szych. Niektóre komponenty techniczne szaprojektowane tak, aby w bezpo redni sposób wspiera podstawowefunkcje innych warstw (na przyk ad poprzez udost pnienie abstrakcyj-nych klas bazowych dla obiektów dziedziny) oraz dostarcza mechanizm doich powi zania (na przyk ad implementacje wzorca MVC i podobnych).Tego rodzaju „szkielet architektury” ma zdecydowanie wi kszy wp ywna projekt innych cz ci programu.

Szkielety architekturyW sytuacji, gdy infrastruktura udost pniana jest w postaci US UG wywo-ywanych przez interfejsy, zrozumienie podzia u na warstwy oraz sposobu

ich utrzymania w sposób lu no zwi zany ze sob jest do intuicyjne.Jednak niektóre problemy techniczne wymagaj bardziej zach annej formyinfrastruktury. Struktury integruj ce wiele potrzeb zwi zanych z infra-struktur wymagaj cz sto, aby inne warstwy by y zaimplementowanew okre lony sposób, na przyk ad jako podklasa klasy szkieletowej lubz uporz dkowanymi sygnaturami metod (wydawa by si mog o bardzonieintuicyjne, aby podklasa by a w warstwie wy szej ni klasa nadrz dna,ale miejmy na uwadze, która z klas zawiera wi cej wiedzy o drugiej).Najlepszy szkielet architektury rozwi zuje z o one problemy techniczne,pozwalaj c programi cie zajmuj cemu si dziedzin skoncentrowa si nawyra eniu modelu. Niemniej jednak szkielet ten mo e tak e stan nadrodze programisty, tworz c na przyk ad zbyt wiele za o e ograniczaj -cych wybór projektu dziedziny lub te tak ci k implementacj , e b dzieto opó nia programowanie.

Pewnego rodzaju szkielet architektury jest zazwyczaj niezb dny (cho-cia niekiedy zespo y wybieraj taki, który niezbyt dobrze im s u y). W trak-cie stosowania szkieletu zespó musi skoncentrowa si na swoim zadaniu,czyli stworzeniu implementacji wyra aj cej model dziedziny, którego u ywa




TO W WARSTWIE DZIEDZINY YJE MODEL 101

do rozwi zania wa nych problemów. To w a nie zespó musi zaadapto-wa szkielet, nawet je eli b dzie to oznacza pomini cie pewnych jegofunkcjonalno ci. Na przyk ad wczesne aplikacje J2EE bardzo cz sto imple-mentowa y wszystkie obiekty dziedziny w postaci „ziaren encyjnych”(ang. entity beans). Takie podej cie wp ywa o negatywnie zarówno nawydajno , jak i tempo programowania. Obecn praktyk jest raczej zasto-sowanie szkieletu J2EE do wi kszych obiektów oraz implementacjawi kszo ci logiki biznesowej przy u yciu prostych obiektów Javy. Wieleogranicze szkieletu architektury mo e by zminimalizowanych poprzezselektywne zastosowanie go do rozwi zania trudnych problemów, bezposzukiwania cudownego rozwi zania na wszystkie bol czki. Rozs dnestosowanie tylko wybranych, najbardziej warto ciowych cz ci rozwi -zania zmniejsza zwi zanie implementacji ze szkieletem architektury, codaje wi ksz elastyczno w pó niejszych decyzjach projektowych. Bior cpod uwag , jak bardzo skomplikowanych jest wiele z obecnie dost pnychszkieletów aplikacji, podej cie minimalistyczne w ich stosowaniu pomagautrzyma obiekty biznesowe w przejrzystej i wymownej postaci.

Szkielety architektury oraz inne narz dzia wspomagaj ce b d wcirozwijane. Nowsze z nich b d automatyzowa i dostarcza wzorce dlacoraz to wi kszej liczby aspektów technicznych aplikacji. Je eli tylkozostan one poprawnie zastosowane, programi ci aplikacji b d mogliw coraz wi kszym stopniu koncentrowa si na modelowaniu podsta-wowych problemów biznesowych, co zwi kszy produktywno zespo uoraz jako pracy. Wybieraj c takie podej cie, musimy wystrzega si nad-miernego optymizmu w stosunku do gotowych rozwi za technicznych— bardzo rozwlek e szkielety mog równie ogranicza programistów.

To w warstwie dziedziny yje modelW wi kszo ci dzisiejszych systemów stosowana jest ARCHITEKTURAWARSTWOWA, która u ywa wielu odmian podej cia do podzia u na war-stwy. Równie wiele ró nych stylów programowania mo e skorzystaz takiego podzia u. Niemniej jednak projekt sterowany dziedzin wymagaistnienia tylko jednej konkretnej warstwy.

Model dziedziny jest zestawem poj . Wyrazem modelu oraz wszyst-kich zwi zanych z nim bezpo rednio elementów dziedziny jest „warstwadziedziny”. Sk adaj si na ni dziedzina oraz implementacja logiki bizne-sowej. W PROJEKCIE STEROWANYM MODELEM struktury programuuzyskane w warstwie dziedziny odzwierciedlaj poj cia tego modelu.





Sytuacja, w której logika dziedziny jest wymieszana z innym kodemprogramu, nie jest zbyt praktyczna. Wyizolowanie dziedziny w procesiejej implementacji jest warunkiem wst pnym dla projektu sterowanegodziedzin .

Antywzorzec inteligentnegointerfejsu u ytkownikaTak w a nie wygl da powszechnie akceptowany wzorzec ARCHITEK-TURY WARSTWOWEJ dla aplikacji obiektowych. Wprawdzie bardzocz sto próbuje si rozdzia u interfejsu u ytkownika od aplikacji oraz dzie-dziny, jednak zbyt rzadko jest on w pe ni osi galny. Dlatego odst pstwaod tego wzorca wymagaj odr bnej dyskusji.

Wiele projektów informatycznych podejmuje prób stosowania znacz-nie mniej wyszukanego podej cia projektowego, nazywanego przeze mnieINTELIGENTNYM INTERFEJSEM U YTKOWNIKA. Jest to jednaktylko alternatywna, roz czna odnoga w rozwoju, niezgodna z podej ciemwymaganym przez projektowanie sterowane dziedzin . Je eli kto pójdziet drog , wi kszo tre ci tej ksi ki nie b dzie mo liwa do zastosowania.Najcz ciej interesuj mnie sytuacje, w których wzorzec INTELIGENT-NEGO INTERFEJSU U YTKOWNIKA nie powinien by stosowany,dlatego z przek sem nazywam go „antywzorcem”. Omówienie go w tymmiejscu b dzie przydatnym orze wieniem i pomo e we wskazaniu przy-czyn, które w dalszej cz ci tej ksi ki decyduj o wyborze trudniejszejcie ki projektowania.

* * *

Projekt ma za zadanie dostarczy prost funkcjonalno , zdomino-wan przez wprowadzanie oraz wy wietlanie danych, z jedynie kilkomaregu ami biznesowymi. W sk ad zespo u projektowego nie wchodz osobyz du ym do wiadczeniem w modelowaniu obiektowym.

W przypadku, gdy niedo wiadczony zespól pracuj cy nadprostym projektem zdecyduje si wypróbowa PROJEKTOWANIESTEROWANE MODELEM z ARCHITEKTUR WARSTWOW ,stanie przed konieczno ci podj cia szybkiej i wymagaj cej nauki.Cz onkowie zespo u b d zmuszeni opanowa zaawansowanenowe technologie oraz da sobie rad z nauk modelowaniaobiektowego (co jest wyzwaniem nawet z pomoc tej ksi ki).




ANTYWZORZEC INTELIGENTNEGO INTERFEJSU U YTKOWNIKA 103

Narzut spowodowany przez zarz dzanie infrastruktur orazwszystkimi warstwami spowoduje wyd u enie prostych zada .Proste projekty maj zazwyczaj krótkie terminy i rednio skom-plikowane oczekiwania. Projekt zostanie z pewno ci przerwany,na d ugo zanim zespó doko czy przypisane do zadania, nie maj cszans na zaprezentowanie wspania ych mo liwo ci zastosowa-nego podej cia.

Nawet je eli zespó b dzie mie wi cej czasu, to bez pomocyeksperta cz onkowie zespo u prawdopodobnie nie dadz rady opa-nowa wymaganych technik. Je eli nawet na koniec pokonaj tewszystkie przeciwno ci, to i tak w ko cu utworz prosty system,w którym nigdy nie b d wymagane bogate funkcjonalno ci.

Bardziej do wiadczone zespo y nie b d musia y i na takie kom-promisy. Oczywi cie, wieloletni programi ci mogliby skróci czas potrzebnyna nauk i zarz dzanie warstwami. Projektowanie sterowane dziedzinsprawdza si najlepiej w przypadku ambitnych projektów i b dzie wyma-ga du ych umiej tno ci programistycznych. Nie wszystkie projekty sambitne i nie wszystkie zespo y projektowe mog opanowa wymaganeumiej tno ci.

Dlatego je eli tylko pozwalaj na to okoliczno ci:Umie ca logik biznesow w interfejsie u ytkownika.

Podziel aplikacj na ma e funkcje i zaimplementuj je jakooddzielne modu y interfejsu, umieszczaj c w nich regu y bizne-sowe. Wykorzystaj baz danych w charakterze wspó dzielonegorepozytorium danych. U yj najbardziej zautomatyzowanychnarz dzi do tworzenia interfejsu u ytkownika oraz programowa-nia wizualnego, jakie tylko s dost pne na rynku.

Herezja! Przecie dobra nowina mówi (i jest g oszona wsz dzie,równie w tej ksi ce), e dziedzina powinna by oddzielona od interfejsuu ytkownika. W rzeczywisto ci bez tego rozdzielenia trudno b dzie zaim-plementowa jak kolwiek metod omawian w tej ksi ce, dlatego tewzorzec INTELIGENTNEGO INTERFEJSU U YTKOWNIKA w kon-tek cie projektowania sterowanego dziedzin mo e by traktowany jako„antywzorzec”. Jednak w niektórych sytuacjach skorzystanie z tego wzorcajest uprawnione. Mówi c szczerze, ma on pewne zalety i w niektórychokoliczno ciach mo e sprawdza si najlepiej — co cz ciowo t umaczy,dlaczego jest tak popularny. Omówienie go w tym miejscu pomo e zro-zumie , dlaczego musimy oddziela warstw aplikacji od dziedziny i, cowi cej, w jakich sytuacjach mogliby my nie chcie tego robi .





Zalety: Dost pna od razu du a wydajno dla prostych aplikacji.

Mniej do wiadczeni programi ci mog u ywa tego wzorcapo pobie nym przeszkoleniu.

Nawet braki w wymaganiach mog zosta rozwi zanepo udost pnieniu prototypu u ytkownikom, a nast pnie szybkimzaadaptowaniu go do ich potrzeb.

Aplikacje s od siebie oddzielone, wi c harmonogram dostarczaniama ych modu ów mo e by opracowany z do du dok adno ci .Rozszerzenie sytemu o dodatkowe proste funkcjonalno ci mo eby atwe.

Z tym wzorcem dobrze wspó pracuj bazy danych, które umo liwiajintegracj na poziomie danych.

Dobra wspó praca z narz dziami 4GL.

Po udost pnieniu aplikacji osoby j utrzymuj ce b d w stanieszybko zmieni jej cz ci, nawet te, których nie b d w staniezrozumie . Ewentualne efekty zmian b d mie tylko lokalny wp ywna konkretny fragment interfejsu u ytkownika.

Wady: Integracja aplikacji jest trudna, o ile nie jest zrobiona poprzez baz

danych.

Nie wyst puje wspó dzielenie kodu oraz nie ma adnego modeluabstrakcyjnego logiki biznesowej. Regu y biznesowe musz byduplikowane w ka dej operacji, której dotycz .

Szybkie prototypowanie oraz przeróbki kodu maj swoje naturalneograniczenia, poniewa brak abstrakcji dziedziny ograniczamo liwo ci zmian.

Z o ono szybko oka e si ograniczeniem nie do przezwyci enia.Dlatego naturaln cie k rozwoju b dzie tworzenie kolejnychprostych aplikacji. Nie ma prostej recepty na wzbogacanie istniej cejlogiki.

W przypadku wiadomego zastosowania tego wzorca zespó mo eunikn du ego narzutu pracy zwi zanej z innymi podej ciami. Cz stpomy k jest podejmowanie si korzystania ze z o onego podej cia doprojektowania w sytuacji, gdy zespó nie jest gotów kontynuowa go naca ej cie ce projektu. Kolejnym cz sto pope nianym b dem jest tworzeniez o onej warstwy infrastrukturalnej i korzystanie z najlepszych narz dzina rynku w projekcie, który w a ciwie tego nie potrzebuje.




ANTYWZORZEC INTELIGENTNEGO INTERFEJSU U YTKOWNIKA 105

U ycie wi kszo ci uniwersalnych j zyków (takich jak Java) w przy-padku tych aplikacji b dzie stanowi do du przesad i b dzie bardzokosztowne. W takiej sytuacji skorzystanie z rozwi za 4GL b dzie najlep-szym sposobem.

Nale y jednak pami ta , i konsekwencj wyboru tego wzorca jestutrudniona migracja do innego podej cia projektowego — wybór ogra-nicza si w a ciwie do zast pienia ca ych aplikacji nowymi. Samo u y-cie j zyków programowania ogólnego przeznaczenia, w rodzaju Javy, nieumo liwi w przysz o ci atwego porzucenia wzorca INTELIGENTNEGOINTERFEJSU U YTKOWNIKA. Je eli wi c wybra e t drog , powi-niene równie dostosowa swoje narz dzia. Nie próbuj si asekurowa .Z samego zastosowania uniwersalnego j zyka nie b dzie wynika elastycz-no systemu. Mo e si to jednak sko czy zwi kszeniem kosztów.

Analogicznie zespó , który wybra drog PROJEKTOWANIA STE-ROWANEGO MODELEM, powinien dostosowa swój projekt od samegopocz tku. Oczywi cie, nawet bardzo do wiadczone, ambitne zespo y pro-jektowe musz rozpocz od prostej funkcjonalno ci i rozwija sw pracw kolejnych etapach. Jednak e te pierwsze czynno ci musz by STE-ROWANE MODELEM z wydzielon warstw dziedziny, gdy w prze-ciwnym razie projekt prawdopodobnie sko czy na podej ciu wykorzystu-j cym INTELIGENTNY INTERFEJS U YTKOWNIKA.

* * *

Wzorzec INTELIGENTNEGO INTERFEJSU U YTKOWNIKA zo-sta tutaj omówiony jedynie po to, aby wyja ni przyczyny sytuacji, wktórych wzorzec ARCHITEKTURY WARSTWOWEJ jest niezb dny dowyizolowania warstwy dziedziny.

Oczywi cie, istniej inne rozwi zania, le ce pomi dzy omówionymiw tym rozdziale wzorcami. Na przyk ad Fowler w swojej ksi ce opisujeSKRYPT TRANSAKCYJNY, który oddziela interfejs u ytkownika od apli-kacji, jednak nie udost pnia modelu obiektowego. P ynie z tego nast -puj cy wniosek: Je eli aplikacja wydziela kod zwi zany z dziedzin w postacispójnego projektu dziedziny lu no zwi zanego z pozosta cz ci systemu, wtedytaka architektura prawdopodobnie mog aby zosta zmodyfikowana do postaci projektusterowanego dziedzin .

Ka dy z innych stylów programowania ma swoje zastosowanie, a Ty,drogi Czytelniku, musisz nauczy si akceptowa kompromis pomi dzyz o ono ci a elastyczno ci . W niektórych sytuacjach brak wydzieleniaprojektu dziedziny mo e by naprawd tragiczny. Je eli masz z o onaplikacj i zdecydowa e si na PROJEKT STEROWANY MODELEM,wytrwaj w tym do ko ca, zatrudnij niezb dnych ekspertów i unikaj INTE-LIGENTNEGO INTERFEJSU U YTKOWNIKA.





Inne rodzaje izolacjiNiestety, poza u ytkownikiem oraz infrastruktur istnieje wiele innychczynników, które mog zepsu delikatny model dziedziny. B dzieszmusia radzi sobie z innymi elementami dziedziny, które nie b d w pe nizintegrowane z Twoim modelem. B dziesz musia tak e wspó pracowaz innymi zespo ami programistów, które b d wykorzystywa inne modeletej samej dziedziny. To wszystko b d czynniki wp ywaj ce na zaciem-nienie modelu oraz zmniejszenie jego przydatno ci. Tymi zagadnieniamizajmiemy si w rozdziale 14., „Utrzymywanie integralno ci modelu”,w którym wprowadzimy takie wzorce jak KONTEKST ZWI ZANY orazWARSTWA OCHRONY PRZED USZKODZENIEM (ang. anticorruptionlayer). Bardzo z o ony model dziedziny mo e sam sta si bezu yteczny.W rozdziale 15., „Destylacja”, zajmiemy si omówieniem metod umo -liwiaj cych warstwie dziedziny oddzielenie poj zasadniczych od tychwspieraj cych.

Tym wszystkim zajmiemy si jednak pó niej. W kolejnym rozdzialenatomiast przyjrzymy si podstawom umo liwiaj cym wspólny rozwójefektywnego modelu dziedziny wraz z jego funkcjonaln implementacj .Ostatecznie najwi kszym zyskiem z jej wydzielenia jest usuni cie wszyst-kich pozosta ych rzeczy z drogi, co u atwia rzeczywiste skoncentrowaniesi na projektowaniu dziedziny.




SKOROWIDZ

A

abstract factory, 168ADAPTER, 411agile, 51AGREGATY, 153, 155–165, 203akceptacja, 429aktywa, 254analiza

dziwnej implementacji, 247zysków, 402

antywzorzec inteligentnegointerfejsu u ytkownika, 102

ARCHITEKTURA WARSTWOWA, 47,95, 101, 142, 443

ASERCJE, 286, 293–297asocjacje, 109, 111, 201, 258asocjacje pomi dzy klasami, 113atrybuty, 117, 201

B

baza danych, 130BUDOWNICZY, 169builder, 169

C

cechy US UGI, 133cel operacji logistycznej, 197chemiczny J ZYK OPUBLIKOWANY, 422CI G A INTEGRACJA, 376, 383, 429, 438ci g a nauka, 44cykl ycia obiektu dziedziny, 153, 154cykliczna referencja, 202czyszczenie pami ci, 129, 153

D

decyzjeproaktywne, 375projektowe, 538zespo owe, 427

definiowanieobiektów, 107poddziedzin, 321to samo ci, 121

deklaratywny styl projektowania, 312destylacja, 443, 451, 473, 530, 534destylacja

modelu, 41strategiczna, 445

diagram UML, 36, 63, 65interakcji, 64klas, 39, 46, 70sekwencji, 64, 346

dialekt, 53dodanie

obiektu, 210operacji obs ugi, 208

dokument, 63, 66, 67destylacji, 465, 467XML, 98

dokumentacja MAP KONTEKSTÓW, 394dokumenty projektowe, 65dost p do

bazy danych, 143, 144US UG, 137WARTO CI, 181

dostosowanie, 432du a spójno , high-cohesion, 108dystrybucja sp aty kapita u, 233dziedzina, 30, 93DZIEDZINY G ÓWNE, 444, 446, 458, 472

E

efekty uboczne metody, 289eksperci dziedzinowi, 61elastyczno projektu, 280, 328elementy

sk adowe projektu, 37, 38, 89wydajnego modelowania, 40

ENCJE, 45, 115–122, 125–130, 158, 199




570 SKOROWIDZ

F

FABRYKA ABSTRAKCYJNA, 168FABRYKI, 154, 166–177

ENCJI, 174WARTO CI, 174

factory method, 168faktoryzacja OGÓLNYCH

PODDZIEDZIN, 473fa szywe pokrewie stwa, 381FASADA, 410funkcja, 287

calculateAccrualsThroughDate(), 251FUNKCJE BEZ EFEKTÓW

UBOCZNYCH, 286–288, 297funkcjonalno

powtórzenie operacji, 206sprawdzanie przydzia u, 215zmiana miejsca przeznaczenia

adunku, 206

G

garbage collection, 153garbage collector, 129generowanie, 270GENERYCZNE PODDOMENY, 286g boka destylacja modelu, 482granice AGREGATU, 203

I

idea J ZYKA WSZECHOBECNEGO, 55identyfikator, 207identyfikator obiektu, 119implementacja, 20

asocjacji, 109ENCJI, 117kolekcji, 212REPOZYTORIÓW, 188REPOZYTORIUM, 185, 186WARSTWY ZAPOBIEGAJ CEJ

USZKODZENIU, 409informacje o projekcie, 65inicjalizacja Itinerary, 58inicjalizator, 288integracja wzorców, 322integralno

modelu, 373procesu zakupowego, 160

INTELIGENTNY INTERFEJSU YTKOWNIKA, 102, 105

interakcje z FABRYK , 168INTERFEJS, 173, 283

US UGI, 100u ytkownika, 96, 102

INTERFEJSY UJAWNIAJ CE ZAMIAR,286, 297

interpretacja asocjacji, 109inwestycja po yczkowa, 230istota programu, 32izolacja, 106izolacja dziedziny, 98, 198

J

J DRO WSPÓ DZIELONE, 376,395–398, 406, 435, 438

J ZYK, 53, 61definiowany modelem, 41Java, 113mówiony, 58naturalny, 70oparty na modelu, 61OPUBLIKOWANY, 420–423, 441pid ynowy, 59UML, 63WSZECHOBECNY, 53, 60, 67, 146, 192

j zyki w a ciwe dziedzinie, 311

K

kalkulator, 254kaskada spostrze e , 326kierunek asocjacji, 110klasa Enterprise, 370KLASY SAMODZIELNE, 304–306kodowanie pakietów, 141KOMPOZYT, 315, 356–361kompromis, 434komunikacja, 51, 528koncepcja trasy, 358KONFORMISTA, 404, 405konstruktor, 207konstruktory publiczne, 172KONTEKST, 425, 430

rezerwacji, 379ZWI ZANY, 55, 106, 372, 376–382,

390, 394, 428, 488, 521, 527, 532KOORDYNATOR APLIKACJI, 99korygowanie po yczki, 235korze AGREGATU, 188, 206koszt utworzenia RDZENIA

ODDZIELONEGO, 475




SKOROWIDZ 571

kryzys, 368kwalifikacja asocjacji, 113kwalifikator, 109

L

lista p ac, 519logika

biznesowa, 94niezmienników, 174

logistyka morska, 213

czeniedwóch systemów, 216FABRYKI z REPOZYTORIUM, 190KONTEKSTÓW, 435, 438paradygmatów, 150SPECYFIKACJI, 313strategii, 531struktur du ej skali, 531, 534warstw, 99

M

magazyn obiektów, 191MAPA KONTEKSTÓW, 376, 386–395,

427, 534, 549mapa nawigacyjna, 91, 445mapowanie

metadanych, 182obiektowo-relacyjne, 267

MECHANIZM, 472SPÓJNO CI, 286w schemacie organizacyjnym, 470

metafora naiwna, 495METAFORY SYSTEMU, 493, 495metoda

anInvoice.isOverdue(), 261asSql(), 269dost pu, accessor method, 109isOverdue(), 261isSafelyPacked(), 274mixIn(), 289

METODYFABRYCZNE, 209refaktoringu, 42testuj ce, 297WYTWÓRCZE, 168, 172, 209

metodyka, 65metodyka zwinna, agile, 51

mieszanie farb, 284, 295mikrorefaktoryzacja, 225minimalizm, 528minimalna abstrakcja dziedziny, 56model, 31, 101

dziedziny, 31, 51, 101firmy spedycyjnej, 243G ÓWNY, 549konta inwestycyjnego, 111ksi gowy, 336logistyki, 213pog biony, 233po yczki, 234transportu morskiego, 476UML, 63, 68wzbogacony wiedz , 41, 57zrefaktoryzowany, 503zrestrukturyzowany, 503

modeledog bne, 48, 226, 227dziedzinowe, 351ksi gowe, 336obiektowe, 149obja niaj ce, 68

modelowanieAGREGATÓW, 154, 212dog bne, 241ENCJI, 120, 212na g os, 58obiektowe, 117poj , 256, 283US UGI, 136WARTO CI, 212wydajne, 40

MODEL-WIDOK-KONTROLER, 99modularno , 145MODUMODU RDZENIA, 481MODU Y, 108, 138–141, 213, 487

DZIEDZINY G ÓWNEJ, 535zwinne, 140

moment prze omowy, 229, 231MVC, model-view-controler, 99

N

nadkomplet, 258naliczanie odsetek, 335naruszony niezmiennik, 162narz dzie QueryService, 112narzut, 375




572 SKOROWIDZ

nas uchiwaniebrakuj cego poj cia, 243j zyka, 242

nazwaklasy, 284WZORCA, 557MODU U, 213

nieobiekty, 149niezmiennik, 128, 164, 174, 256niezmienniki AGREGATU, 159normalizacja, 192notacja UML, 51numer

PESEL, 123Social Security, 123

O

obiekt, 108Brokerage Account, 111, 170Cargo, 197, 199Catalog Part, 173Charge, 373Container, 274Customer, 199Delivery History, 198Delivery Specification, 197, 198Facility, 231, 238Invoice, 263Itinerary, 58Loan, 238Location, 200Packer, 275Paint, 291poj ciowy, 144REPOSITORY, 268Route Specification, 58Routing Service, 58Share Pie, 238, 325SharePie, 326, 329SPECIFICATION, 268Strategia, 221Trade Order, 170typu Cargo, 46typu Voyage, 46

obiektydziedziny, 259niezmienne, 128referencyjne, 115WARTO CI, 128z o one, 168

OBSERWATOR, 99

obs uga XML, 423oczekiwania komponentu podrz dnego, 402oddelegowanie implementacji, 455oddzielanie

polece , 324RDZENIA, 476warstwy aplikacji od dziedziny, 103

ODDZIELNE DROGI, 376, 415–417, 435odkrywanie poj niejawnych, 241odnajdowanie tras, 352odpowiedzialno ci

dziedziny, 219operacyjne, 498potencja u, 499wsparcia decyzji, 500

odpytywanie REPOZYTORIUM, 184odsetki, 247, 335odszukiwanie, 266odtwarzanie obiektu, 175–177odwo ania zwrotne, 99OGÓLNE PODDZIEDZINY, 454,

459, 471ograniczenia, 257, 259

asocjacji, 110, 114kierunku interpretacji, 111

okre lanie strategii, 536operacje, 507

obs ugi, 208spedycyjne, 200na to samo ci, 121

operatorAND, 316, 318NOT, 318

OPIS WIZJI, 468OPIS WIZJI DZIEDZINY, 461, 462, 463opowiadanie historii, 506optymalizacja bazy danych, 130opublikowany projekt, 454organizacja, 394osadzanie regu y, 268oszacowanie, 536OTWARTE US UGI GOSPODARZA, 395

P

PAKIETY, 138pakowacz, 272, 275paradygmat

obiektowy, 146relacyjny, 152

paradygmaty modelowania, 146partycjonowanie, 144




SKOROWIDZ 573

PCB, printed-circuit board, 35plan g ówny, 542pocz tkowy stan zamówienia, 161PODDZIEDZINY, 322, 535PODDZIEDZINY OGÓLNE, 444, 452podejmowanie decyzji, 539podzia

na pakiety, 144na partycje, 144na warstwy, 97, 498systemu informatycznego, 95podzia us ug, 136

poj ciaukryte, 325wysokopoziomowe, 283

polimorfizm, 171polityka, policy, 47, 351, 508

nadkompletu, 48, 258trasowania, 352, 503

po czenie modelu z implementacj , 107poprawa wydajno ci, 219PORZ DEK EWOLUCYJNY, 490, 505poszukiwanie poj , 253potencja , 507powi zanie

warstw, 99wzorców projektowych, 349

powtarzanie prób, 255POZIOM WIEDZY, 511–520poziomy refaktoryzacji, 224pozycja, 238po yczka, 234predykat, 261proces, 259

odkrywania, 228projektowania, 20XP, 22

programowanie ekstremalne, 21, 66programowanie

ekstremalne, XP, 21obiektowe, 94wizualne, 103

projektAGREGATU, 209dla programistów, 366dystrybucji p atno ci, 323elastyczny, 279G ÓWNEJ DZIEDZINY, 371STEROWANY MODELEM, 89, 101,

107, 146, 151, 264strategiczny, 369, 540ubezpiecze , 416

projektowanieasocjacji, 131, 201deklaratywne, 310, 311interfejsu, 173, 409kontraktowe, 90modeli, 224obiektów, 190OBIEKTÓW WARTO CI, 128obwodów drukowanych, 35operacji, 121sterowane dziedzin , 17, 31, 93, 283STEROWANE MODELEM, 68, 91, 105STEROWANE MODELEM

z ARCHITEKTURWARSTWOW , 102

sterowane odpowiedzialno ci , 90projekty elastyczne, 227, 529prototyp, 277prototyp pakowacza, 275przechowywanie danych, 150przegl danie scenariuszy, 206przekszta canie granic, 428prze om, 229–231przep yw

informacji, 216zada , 150

przetwarzaniewiedzy, 35, 41wsadowe, 341

R

RDZE , 458ABSTRAKCYJNY, 481, 521, 548DZIEDZINY, 449ODDZIELONY, 474–479oznaczony, 466WYRÓ NIONY, 464–468

realizacja produkcji, 523refaktoring, 167, 209

implementacji, 45modelu obiektowego, 193

refaktoryzacja, 223, 236, 284, 363–368,483, 527aplikacji, 289kodu, 261obiektu, 290ograniczenia, 257

referencja, 178, 202referencje do obiektów, 158REFLEKSJA, 516regu a wymagalno ci, 264




574 SKOROWIDZ

regu ybiznesowe, 262ksi gowania, 341, 346

czenia nieobiektowych elementów, 151organizacji, 515

relacjekwalifikowane, 110pomi dzy elementami

AGREGATU, 158pomi dzy KONTEKSTAMI

ZWI ZANYMI, 395z FABRYKAMI, 189

relacyjne bazy danych, 112, 190, 267REPOZYTORIA, 154, 178–190, 202, 269repozytorium faktur, 266restrukturyzacja, 529rezerwacje, 402, 413RGB, 290rodzaj wiedzy, 45rodzaje

dzia alno ci, 508izolacji, 106

rola, 197, 201Routing Service, 56rozdzielanie zagadnie , 95rozdzielenie warstw, 98rozpoznawanie odprysków poj ciowych, 381rozró nianie ENCJI oraz WARTO CI, 199rozszerzalny j zyk znaczników, 421rozszerzenie

AGREGATU, 170j zyka, 62SPECYFIKACJI, 313

rozwijanie decyzji zespo owych, 476ryzyko projektowe, 459

S

samodyscyplina, 528samodzielna implementacja, 455scenariusz refaktoryzacji, 363scenariusze, 206schemat organizacyjny, 470, 472SEGMENT PRZEDSI BIORSTWA, 219segmentacja biznesu, 217serializacja, 122sie cie ek, 37silniki regu biznesowych, 145, 150SINGLETON, 137SKRYPT TRANSAKCYJNY, 105s abe zwi zanie, loose-coupling, 108

SPECYFIKACJA, 185, 197, 260–274, 315,317, 319Arystotelesa, 321KOMPOZYTU, 317

SPÓJNE MECHANIZMY, 469, 471, 473spójno zmian, 156SPÓJNY MECHANIZM, 469–471sprzeczno ci, 252SQL, 113, 268standaryzowany produkt, 453stosowanie wzorców analitycznych, 333STRATEGIA, 47, 351–355, 536strefy czasowe, 458struktura, 502, 504, 526, 537struktury du ej skali, 485, 524styl deklaratywny, 473subsumpcja, 318, 320system

automatyzacji fabryki, 509bankowo ci inwestycyjnej, 510do wyp at pracowniczych, 518do wyp at pracowniczych, 512logistyczny, 195logistyki morskiej, 498obs ugi zamówienia, 160w projektowaniu, 431zewn trzny, 430

systemyklasy Enterprise, 370wsparcia decyzji, 508

szablony, 553szkielet

architektury, 100, 188CIM, 524j zyka, 54KOMPONENTÓW

DO CZANYCH, 521, 524SEMATECH CIM, 523techniczny, 541

ledzeniep atno ci, 116to samo ci ENCJI, 126

T

testowanie, 297, 394j zyka, 54trasy, 391

topologia, 37, 39




SKOROWIDZ 575

to samo , 121ENCJI, 117, 126globalna, 158lokalna, 158

transakcje, 238transformacje, 435trasowanie, 353, 503tworzenie

AGREGATU, 171elementu narzuty, 525harmonogramów, 456interfejsu u ytkownika, 103modelu, 36modelu dziedziny, 91na zamówienie, 270obiektów, 167, 207obiektów z o onych, 168pakietów, 142RDZENIA ODDZIELONEGO, 475REPOZYTORIUM, 211

U

ujawnianie ukrytych poj , 325ukryte poj cie, 45UML, Unified Modeling Language, 51, 63unifikacja, 375UPORZ DKOWANIE EWOLUCYJNE,

510US UGA, service, 99, 107, 132–135, 217

aplikacyjna, 136dziedzinowa, 136infrastrukturalna, 136OTWARTEGO GOSPODARZA,

418, 420, 441trasowania, 56, 353

usuwanieasocjacji, 109zatorów projektowych, 277

utrzymywanie integralno ci, 373u ywanie

j zyka, 51, 195J ZYKA WSZECHOBECNEGO,

54, 62

W

walidacja, 265warstwa, 95, 97

aplikacji, 96, 97dziedziny, 96, 97, 101, 134infrastruktury, 96, 99

interfejsu u ytkownika, 96, 97OCHRONY PRZED

USZKODZENIEM, 106potencja u, 509prezentacji, 96ZAPOBIEGAJ CA

USZKODZENIU, 218,407–414, 430

zobowi zania, 509warstwy

powi zania, 99DZIEDZINY, 267MAPOWANIA METADANYCH, 180ODPOWIEDZIALNO CI, 496, 505,

526, 533WARTO CI, 125–131, 181WARTO , value-object, 107warunki brzegowe, 59wdro enie, 433wiedza biznesowa, 164wielorako relacji, 109WIZJA DZIEDZINY, 461wprowadzenie aplikacji, 198wsparcie decyzji, 508wspó dzielenie

bazy danych, 161obiektów, 128

wybór, 266celów refaktoryzacji, 483FABRYK, 169RDZENIA dziedziny, 449REPOZYTORIÓW, 204strategii kontekstu modelu, 427warstw, 505z kolekcji, 308

wyci ganie poj , 242wyczucie czasu, 367wydajno , 219wydobywanie ukrytego poj cia, 45wygaszanie systemu, 439wyizolowanie dziedziny, 93wykonywanie regu ksi gowania, 342wymagania, 434wymagania specjalizowane, 375wymogi infrastruktury, 142wymuszanie

niezmienników, 161niezmiennika AGREGATU, 165

wy wietlanie informacji, 96wyznaczanie trasy adunku, 499wzbogacony model dziedziny, 57




576 SKOROWIDZ

wzorceanalityczne, 217, 333, 346destylacyjne, 460elementów modelu, 107projektowe, 349

wzorzecARCHITEKTURY WARSTWOWEJ,

102INTELIGENTNEGO INTERFEJSU

U YTKOWNIKA, 103, 105PY KU, 361REPOZYTORIUM, 182ROZDZIELENIA MODELU-

WIDOKU, 99SEGMENT PRZEDSI BIORSTWA,

219SINGLETON, 137PECYFIKACJI, 197STRATEGIA, 47S

X

XP, extreme programming, 21

Z

zablokowanie zamówienia, 163zachowanie obiektu, 64zakleszczenie, 164zakres US UGI, 100zalety REPOZYTORIÓW, 183zale no ci

poj ciowe, 506, 509, 510projektowe, 99

ZAMKNI CIE OPERACJI, 307–310, 327zap ata, 237zapytanie, 179, 182, 184

oparte na SPECYFIKACJI, 185SQL, 268

ZARYSYKONCEPCYJNE, 298–303, 507, 529sum przyrostowych, 300

zarz dzaniekontami bankowymi, 97obiektami, 153ryzykiem projektowym, 459zmian , 161

zasada podwójnego ksi gowania, 337zastosowanie

modelu dziedziny, 29SPECYFIKACJI, 264

zduplikowane poj cia, 381ZESPO Y PROGRAMISTYCZNE

KLIENTA – DOSTAWCY, 399zespó , 60zespó architektoniczny, 538ziarna encyjne, 101ziarnisto , 136z o one funkcjonalno ci, 19zmiana

J ZYKA WSZECHOBECNEGO, 55refaktoryzacyjna, 237

zmienna logiczna, 56zwi kszanie destylacji, 451zwrot z refaktoryzacji, 229




http://program-partnerski.helion.pl

Tytuł oryginału: Domain-Driven Design: Tackling Complexity ... · kowaÊ przez sieci komputerowe,...

Documents

Transcript of Tytuł oryginału: Domain-Driven Design: Tackling Complexity ... · kowaÊ przez sieci komputerowe,...