Upload
vantuyen
View
229
Download
0
Embed Size (px)
Citation preview
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ść
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
14 SPIS TRE CI
Zako czenie ........................................................ 545Dodatek ..........................................................................................553Wykorzystanie szablonów z tej ksi ki ............................................553S ownik .........................................................................................559Bibliografia .....................................................................................565Prawa do zdj ................................................................................567Skorowidz ......................................................................................569
Poleć książkęKup książkę
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
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.
Poleć książkęKup książkę
96 ROZDZIA 4. WYIZOLOWANIE DZIEDZINY
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.
Poleć książkęKup książkę
ARCHITEKTURA WARSTWOWA 97
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”.
Poleć książkęKup książkę
98 ROZDZIA 4. WYIZOLOWANIE DZIEDZINY
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.
Poleć książkęKup książkę
ARCHITEKTURA WARSTWOWA 99
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
Poleć książkęKup książkę
100 ROZDZIA 4. WYIZOLOWANIE DZIEDZINY
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
Poleć książkęKup książkę
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.
Poleć książkęKup książkę
102 ROZDZIA 4. WYIZOLOWANIE DZIEDZINY
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).
Poleć książkęKup książkę
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 .
Poleć książkęKup książkę
104 ROZDZIA 4. WYIZOLOWANIE DZIEDZINY
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.
Poleć książkęKup książkę
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.
Poleć książkęKup książkę
106 ROZDZIA 4. WYIZOLOWANIE DZIEDZINY
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.
Poleć książkęKup książkę
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę