Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00011 003931 12912822 na godz. na dobę w sumie
Domain-Driven Design. Zapanuj nad złożonym systemem informatycznym - ebook/pdf
Domain-Driven Design. Zapanuj nad złożonym systemem informatycznym - ebook/pdf
Autor: Liczba stron: 584
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-283-0528-1 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> techniki programowania
Porównaj ceny (książka, ebook (-40%), audiobook).

Zmień sposób myślenia o projektowaniu systemów informatycznych!

Tworzenie skomplikowanych systemów informatycznych wymaga nowego podejścia. Dotychczas stosowane metody przestają się sprawdzać i generują mnóstwo problemów. Odpowiedzią na nie jest DomainDriven Design, w skrócie DDD. W tym podejściu szczególny nacisk kładzie się na tworzenie obiektów dokładnie odzwierciedlających zachowanie ich odpowiedników istniejących w rzeczywistości. Dzięki temu projektowanie systemu można powierzyć ekspertom z danej branży, którzy niekoniecznie muszą być specjalistami w dziedzinie projektowania architektury systemów informatycznych.

Ta książka jest niezwykłym przewodnikiem, który wprowadzi Cię w świat DDD. Sięgnij po nią i poznaj elementy składowe projektu sterowanego modelem oraz cykl życia obiektu dziedziny. W trakcie lektury kolejnych rozdziałów dowiesz się, jak odkrywać pojęcia niejawne, stosować wzorce analityczne oraz wiązać wzorce projektowe z modelem. Ponadto zobaczysz, w jaki sposób utrzymywać integralność modelu, a na sam koniec zaznajomisz się ze strukturami dużej skali oraz łączeniem strategii. Ta książka jest doskonałą lekturą dla wszystkich osób chcących zrozumieć DomainDriven Design oraz zastosować to podejście w praktyce!

Dzięki tej książce:

Sprawdź, jak projektować skomplikowane systemy informatyczne!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Tytuł oryginału: Domain-Driven Design: Tackling Complexity in the Heart of Software Tłumaczenie: Rafał Szpoton Projekt okładki: Studio Gravite / Olsztyn Obarek, 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 HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl WWW: 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/domdri Moż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ść SPIS TRE(cid:165)CI Przedmowa ...................................................................................... 15 Wst(cid:218)p .............................................................................................. 17 Podzi(cid:218)kowania ................................................................................. 27 Cz(cid:218)(cid:258)(cid:202) I Zastosowanie modelu dziedziny ..........................29 Rozdzia(cid:239) 1. Przetwarzanie wiedzy ................................................... 35 Elementy wydajnego modelowania ................................................40 Przetwarzanie wiedzy ......................................................................41 Ci(cid:200)g(cid:239)a nauka .....................................................................................44 Projekt bogaty w wiedz(cid:218) .................................................................45 Modele dog(cid:239)(cid:218)bne .............................................................................48 Rozdzia(cid:239) 2. Komunikacja i u(cid:285)ycie j(cid:218)zyka ......................................... 51 J(cid:218)zyk wszechobecny ........................................................................52 Modelowanie na g(cid:239)os .......................................................................58 Jeden zespó(cid:239), jeden j(cid:218)zyk .................................................................60 Dokumenty i diagramy ...................................................................63 Spisane dokumenty projektowe ....................................................65 Wykonywalna podstawa .............................................................68 Modele obja(cid:258)niaj(cid:200)ce .........................................................................68 Rozdzia(cid:239) 3. Zwi(cid:200)zanie modelu z implementacj(cid:200) ............................... 71 Projektowanie sterowane modelem ...............................................73 Paradygmaty modelowania i narz(cid:218)dzia wspieraj(cid:200)ce ......................76 Projekt mechaniczny ...................................................................79 Projekt sterowany modelem .........................................................80 Odkrywanie szkieletu — dlaczego modele s(cid:200) wa(cid:285)ne dla u(cid:285)ytkowników .........................................................................83 Modelowanie praktyczne ................................................................86 7 Poleć książkęKup książkę Cz(cid:218)(cid:258)(cid:202) II Elementy sk(cid:239)adowe projektu sterowanego modelem .......................................... 89 Rozdzia(cid:239) 4. Wyizolowanie dziedziny ...............................................93 Architektura warstwowa ................................................................. 94 Powi(cid:200)zanie warstw .................................................................... 99 Szkielety architektury ............................................................... 100 To w warstwie dziedziny (cid:285)yje model ........................................... 101 Antywzorzec inteligentnego interfejsu u(cid:285)ytkownika .................. 102 Inne rodzaje izolacji ...................................................................... 106 Rozdzia(cid:239) 5. Wyra(cid:285)enie modelu w programie ...................................107 Asocjacje ........................................................................................ 109 ENCJE (zwane równie(cid:285) obiektami referencyjnymi) .................. 115 Modelowanie ENCJI .............................................................. 120 Projektowanie operacji na to(cid:285)samo(cid:258)ci ......................................... 121 WARTO(cid:165)CI .................................................................................. 125 Projektowanie OBIEKTÓW WARTO(cid:165)CI ............................ 128 Projektowanie asocjacji korzystaj(cid:200)cych z WARTO(cid:165)CI .............. 131 US(cid:146)UGI ........................................................................................ 132 US(cid:146)UGI a wyizolowana warstwa dziedziny .......................... 134 Ziarnisto(cid:258)(cid:202) ............................................................................... 136 Dost(cid:218)p do US(cid:146)UG ................................................................. 137 MODU(cid:146)Y (zwane równie(cid:285) PAKIETAMI) ................................ 138 MODU(cid:146)Y zwinne (agile modules) ......................................... 140 Pu(cid:239)apki tworzenia pakietów na podstawie wymogów infrastruktury ........................................................................ 142 Paradygmaty modelowania ........................................................... 146 Dlaczego dominuje paradygmat obiektowy? ............................... 146 Nieobiekty w (cid:258)wiecie obiektowym .............................................. 149 Utrzymywanie PROJEKTU STEROWANEGO MODELEM w przypadku (cid:239)(cid:200)czenia paradygmatów .............. 150 Rozdzia(cid:239) 6. Cykl (cid:285)ycia obiektu dziedziny .......................................153 AGREGATY .................................................................................. 155 FABRYKI ....................................................................................... 166 Wybór FABRYK oraz ich miejsc .............................................. 169 Kiedy potrzebujesz jedynie konstruktora .................................... 171 Projektowanie interfejsu ............................................................ 173 8 SPIS TRE(cid:165)CI Poleć książkęKup książkę Gdzie mie(cid:258)ci si(cid:218) logika niezmienników? ....................................174 FABRYKI ENCJI a FABRYKI WARTO(cid:165)CI ......................174 Odtwarzanie zachowanych obiektów .........................................175 REPOZYTORIA ...........................................................................178 Odpytywanie REPOZYTORIUM .........................................184 Kod klienta, w przeciwie(cid:241)stwie do programistów, ignoruje implementacj(cid:218) REPOZYTORIUM .........................185 Implementacja REPOZYTORIUM ........................................186 Praca ze szkieletami architektury ...............................................188 Relacje z FABRYKAMI ..........................................................189 Projektowanie obiektów dla relacyjnych baz danych ..................190 Rozdzia(cid:239) 7. U(cid:285)ycie j(cid:218)zyka — przyk(cid:239)ad rozszerzony ....................... 195 Prezentacja systemu logistycznego dla (cid:239)adunku ..........................195 Izolowanie dziedziny — wprowadzenie aplikacji ........................198 Rozró(cid:285)nianie ENCJI oraz WARTO(cid:165)CI ......................................199 Role (rola) oraz inne atrybuty ....................................................201 Projektowanie asocjacji w dziedzinie logistyki morskiej .............201 Granice AGREGATU ...................................................................203 Wybór REPOZYTORIÓW ..........................................................204 Przegl(cid:200)danie scenariuszy ...............................................................206 Przyk(cid:239)adowa funkcjonalno(cid:258)(cid:202) aplikacji — zmiana miejsca przeznaczenia (cid:239)adunku ..........................................................206 Przyk(cid:239)adowa funkcjonalno(cid:258)(cid:202) aplikacji — powtórzenie operacji ....206 Tworzenie obiektów .....................................................................207 FABRYKI oraz konstruktory klasy Cargo .................................207 Dodanie operacji obs(cid:239)ugi ............................................................208 Przerwa na refaktoring — projekt alternatywny AGREGATU Cargo ...................................................................209 MODU(cid:146)Y w modelu logistyki morskiej .....................................213 Nowa funkcjonalno(cid:258)(cid:202) — sprawdzanie przydzia(cid:239)u ......................215 (cid:146)(cid:200)czenie dwóch systemów .........................................................216 Wzbogacanie modelu — segmentacja biznesu .............................217 Poprawa wydajno(cid:258)ci .................................................................219 Ostateczna wersja ..........................................................................220 SPIS TRE(cid:165)CI 9 Poleć książkęKup książkę Cz(cid:218)(cid:258)(cid:202) III Refaktoryzacja ku g(cid:239)(cid:218)bszemu zrozumieniu ....... 223 Rozdzia(cid:239) 8. Moment prze(cid:239)omowy ...................................................229 Historia pewnego prze(cid:239)omu ......................................................... 230 Przyzwoity model, lecz wci(cid:200)(cid:285)... ................................................ 230 Moment prze(cid:239)omowy ................................................................ 231 Model pog(cid:239)(cid:218)biony ..................................................................... 233 Otrze(cid:283)wiaj(cid:200)ca decyzja .............................................................. 236 Zap(cid:239)ata ................................................................................... 237 Mo(cid:285)liwo(cid:258)ci .................................................................................... 237 Koncentracja na podstawach ......................................................... 237 Epilog — potok nowych spostrze(cid:285)e(cid:241) ........................................... 238 Rozdzia(cid:239) 9. Odkrywanie poj(cid:218)(cid:202) niejawnych ......................................241 Wyci(cid:200)ganie poj(cid:218)(cid:202) ........................................................................... 242 Nas(cid:239)uchiwanie j(cid:218)zyka .............................................................. 242 Analiza dziwnej implementacji ................................................. 247 Rozmy(cid:258)lanie nad sprzeczno(cid:258)ciami ............................................. 252 Czytanie ksi(cid:200)(cid:285)ki ...................................................................... 253 Wielokrotne powtarzanie prób .................................................. 255 W jaki sposób zamodelowa(cid:202) mniej oczywiste poj(cid:218)cia ................. 256 Procesy jako obiekty dziedziny .................................................. 259 SPECYFIKACJA .................................................................. 261 Zastosowanie SPECYFIKACJI w implementacji ..................... 264 Rozdzia(cid:239) 10. Projekt elastyczny ......................................................279 INTERFEJSY UJAWNIAJ(cid:107)CE ZAMIAR ................................. 283 FUNKCJE BEZ EFEKTÓW UBOCZNYCH ......................... 287 ASERCJE ....................................................................................... 293 Teraz widzimy lepiej ............................................................... 296 ZARYSY KONCEPCYJNE ......................................................... 298 Nieprzewidziana zmiana ......................................................... 301 KLASY SAMODZIELNE ............................................................ 304 ZAMKNI(cid:125)CIE OPERACJI ......................................................... 307 Projektowanie deklaratywne ......................................................... 310 J(cid:218)zyki w(cid:239)a(cid:258)ciwe dziedzinie ....................................................... 311 Deklaratywny styl projektowania ................................................. 312 Rozszerzenie SPECYFIKACJI w stylu deklaratywnym ........... 313 Subsumpcja ............................................................................. 318 10 SPIS TRE(cid:165)CI Poleć książkęKup książkę Kierunki ataku ................................................................................321 Definiowanie poddziedzin ........................................................321 W miar(cid:218) mo(cid:285)liwo(cid:258)ci polegaj na ustalonym formalizmie ...............322 Rozdzia(cid:239) 11. Stosowanie wzorców analitycznych ............................ 333 Rozdzia(cid:239) 12. Powi(cid:200)zanie wzorców projektowych z modelem ........... 349 STRATEGIA (zwana równie(cid:285) POLITYK(cid:107)) ...............................351 KOMPOZYT ................................................................................356 Dlaczego nie wzorzec PY(cid:146)KU (FLYWEIGHT)? ........................361 Rozdzia(cid:239) 13. Refaktoryzacja ku g(cid:239)(cid:218)bszemu zrozumieniu ................. 363 Pocz(cid:200)tek .........................................................................................364 Zespo(cid:239)y poszukiwawcze ................................................................364 Wcze(cid:258)niejsze odkrycia ...................................................................365 Projekt dla programistów ..............................................................366 Wyczucie czasu ..............................................................................367 Kryzys jako (cid:283)ród(cid:239)o mo(cid:285)liwo(cid:258)ci .....................................................368 Cz(cid:218)(cid:258)(cid:202) IV Projekt strategiczny .............................................369 Rozdzia(cid:239) 14. Utrzymywanie integralno(cid:258)ci modelu ........................... 373 KONTEKST ZWI(cid:107)ZANY ..........................................................377 Rozpoznawanie odprysków poj(cid:218)ciowych w KONTEK(cid:165)CIE ZWI(cid:107)ZANYM ...................................381 CI(cid:107)G(cid:146)A INTEGRACJA ..............................................................383 MAPA KONTEKSTÓW .............................................................386 Testowanie na granicach KONTEKSTU ................................393 Organizacja oraz dokumentacja MAP KONTEKSTÓW ........394 Relacje pomi(cid:218)dzy KONTEKSTAMI ZWI(cid:107)ZANYMI ..............395 J(cid:107)DRO WSPÓ(cid:146)DZIELONE ......................................................396 ZESPO(cid:146)Y PROGRAMISTYCZNE KLIENTA – DOSTAWCY ........................................................398 KONFORMISTA .........................................................................403 WARSTWA ZAPOBIEGAJ(cid:107)CA USZKODZENIU ................406 Projektowanie interfejsu WARSTWY ZAPOBIEGAJ(cid:107)CEJ USZKODZENIU .............................................................408 Implementacja WARSTWY ZAPOBIEGAJ(cid:107)CEJ USZKODZENIU .............................................................408 Opowie(cid:258)(cid:202) ku przestrodze ...........................................................412 SPIS TRE(cid:165)CI 11 Poleć książkęKup książkę ODDZIELNE DROGI ................................................................ 414 US(cid:146)UGA OTWARTEGO GOSPODARZA ............................ 417 J(cid:125)ZYK OPUBLIKOWANY ......................................................... 419 Unifikacja s(cid:239)onia ............................................................................ 422 Wybór strategii kontekstu modelu ............................................... 426 Decyzja zespo(cid:239)owa lub wy(cid:285)sza ................................................. 426 Stawianie siebie w kontek(cid:258)cie .................................................... 427 Przekszta(cid:239)canie granic .............................................................. 427 Akceptacja tego, czego nie mo(cid:285)emy zmieni(cid:202) — wyznaczanie zewn(cid:218)trznych systemów ................................ 428 Relacje z systemami zewn(cid:218)trznymi ............................................ 429 System w projektowaniu ........................................................... 430 Dostosowanie do specjalnych potrzeb przy u(cid:285)yciu odr(cid:218)bnych modeli ................................................................... 431 Wdro(cid:285)enie ............................................................................... 432 Kompromis .............................................................................. 433 Kiedy projekt ju(cid:285) trwa .............................................................. 433 Transformacje ............................................................................... 434 (cid:146)(cid:200)czenie KONTEKSTÓW — ODDZIELNE DROGI (cid:314) J(cid:107)DRO WSPÓ(cid:146)DZIELONE .......................................... 434 (cid:146)(cid:200)czenie KONTEKSTÓW — J(cid:107)DRO WSPÓ(cid:146)DZIELONE (cid:314) CI(cid:107)G(cid:146)A INTEGRACJA ....... 437 Wygaszanie starego systemu ...................................................... 438 US(cid:146)UGA OTWARTEGO GOSPODARZA (cid:314) J(cid:125)ZYK OPUBLIKOWANY ............................................. 440 Rozdzia(cid:239) 15. Destylacja ..................................................................443 DZIEDZINA G(cid:146)ÓWNA ............................................................ 446 Wybór RDZENIA dziedziny .................................................. 449 Kto wykonuje prace? ................................................................ 449 Zwi(cid:218)kszanie destylacji ................................................................... 451 PODDZIEDZINY OGÓLNE .................................................... 452 Ogólny nie oznacza mo(cid:285)liwy do ponownego wykorzystania ....... 459 Zarz(cid:200)dzanie ryzykiem projektowym ......................................... 459 OPIS WIZJI DZIEDZINY .......................................................... 461 RDZE(cid:148) WYRÓ(cid:191)NIONY .......................................................... 464 Dokument destylacji ................................................................. 465 RDZE(cid:148) oznaczony ................................................................ 466 Dokument destylacji jako narz(cid:218)dzie procesowe ........................... 467 12 SPIS TRE(cid:165)CI Poleć książkęKup książkę SPÓJNE MECHANIZMY ..........................................................469 OGÓLNE PODDZIEDZINY a SPÓJNE MECHANIZMY ............................................471 Kiedy MECHANIZM jest cz(cid:218)(cid:258)ci(cid:200) DZIEDZINY G(cid:146)ÓWNEJ ................................................472 Destylacja do stylu deklaratywnego ..............................................473 RDZE(cid:148) ODDZIELONY ............................................................474 Koszt utworzenia RDZENIA ODDZIELONEGO ..............475 Rozwijanie decyzji zespo(cid:239)owych ................................................476 RDZE(cid:148) ABSTRAKCYJNY .........................................................481 G(cid:239)(cid:218)boka destylacja modelu ...........................................................482 Wybór celów refaktoryzacji ...........................................................483 Rozdzia(cid:239) 16. Struktury du(cid:285)ej skali ................................................. 485 PORZ(cid:107)DEK EWOLUCYJNY ....................................................490 METAFORA SYSTEMU .............................................................493 Dlaczego nie potrzebujemy metafory „naiwnej” ..........................495 WARSTWY ODPOWIEDZIALNO(cid:165)CI .....................................496 W jaki sposób struktura wp(cid:239)ywa na bie(cid:285)(cid:200)cy projekt? ...................502 Wybór odpowiednich warstw .....................................................505 POZIOM WIEDZY ......................................................................511 SZKIELET KOMPONENTÓW DO(cid:146)(cid:107)CZANYCH ..............521 Jak ograniczaj(cid:200)ca powinna by(cid:202) struktura? ....................................526 Refaktoryzacja ku lepiej dopasowanej strukturze ........................527 Minimalizm ............................................................................528 Komunikacja oraz samodyscyplina .............................................528 Restrukturyzacja przyczynia si(cid:218) do projektu elastycznego .............529 Destylacja zmniejsza obci(cid:200)(cid:285)enie ................................................530 Rozdzia(cid:239) 17. (cid:146)(cid:200)czenie strategii ....................................................... 531 (cid:146)(cid:200)czenie struktur du(cid:285)ej skali z KONTEKSTAMI ZWI(cid:107)ZANYMI .......................................531 (cid:146)(cid:200)czenie struktur du(cid:285)ej skali oraz destylacji ................................534 Najpierw oszacowanie ...................................................................536 Kto okre(cid:258)la strategi(cid:218)? .....................................................................536 Powstawanie struktury w trakcie tworzenia aplikacji ..................537 Zespó(cid:239) architektoniczny skoncentrowany na kliencie ....................538 Sze(cid:258)(cid:202) podstawowych kryteriów dotycz(cid:200)cych podejmowania strategicznych decyzji projektowych .........................................538 To samo dotyczy szkieletów technicznych ...................................541 Wystrzegaj si(cid:218) planu g(cid:239)ównego ...................................................542 SPIS TRE(cid:165)CI 13 Poleć książkęKup książkę Zako(cid:241)czenie ........................................................ 545 Dodatek ..........................................................................................553 Wykorzystanie szablonów z tej ksi(cid:200)(cid:285)ki ............................................553 S(cid:239)ownik .........................................................................................559 Bibliografia .....................................................................................565 Prawa do zdj(cid:218)(cid:202) ................................................................................567 Skorowidz ......................................................................................569 14 SPIS TRE(cid:165)CI Poleć książkęKup książkę ROZDZIA(cid:146) 4. Wyizolowanie dziedziny F ragment oprogramowania, który adresuje g(cid:239)ówne problemy dzie- dziny, stanowi najcz(cid:218)(cid:258)ciej tylko ma(cid:239)(cid:200) cz(cid:218)(cid:258)(cid:202) ca(cid:239)ego systemu informatycznego. Niemniej jednak jego znaczenie jest nieproporcjonalne w stosunku do rozmiaru. Aby móc zastosowa(cid:202) nasze najlepsze pomys(cid:239)y, musimy by(cid:202) w stanie dostrzec w poszczególnych elementach modelu ca(cid:239)y system. Nie mo(cid:285)emy by(cid:202) zmuszeni do wybierania ich z wi(cid:218)kszego zestawu obiek- tów, tak jak gwiazdozbiorów na nocnym niebie. Musimy oddzieli(cid:202) obiekty dziedziny od innych funkcji systemu, aby nie miesza(cid:202) poj(cid:218)(cid:202) dziedzinowych z innymi, zwi(cid:200)zanymi jedynie z technologi(cid:200) oprogramowania. W g(cid:200)szczu ca(cid:239)ego systemu nie mo(cid:285)emy te(cid:285) straci(cid:202) z oczu samej dziedziny. W tym celu powsta(cid:239)y zaawansowane techniki s(cid:239)u(cid:285)(cid:200)ce do wyizolo- wania dziedziny. To dobrze znany obszar, lecz jest on tak istotny w prawi- d(cid:239)owym zastosowaniu pryncypiów modelowania dziedzinowego, (cid:285)e musi zosta(cid:202) w tym miejscu krótko omówiony z punktu widzenia projektowania sterowanego dziedzin(cid:200). 93 Poleć książkęKup książkę Architektura warstwowa W przypadku prostej aplikacji wspieraj(cid:200)cej u(cid:285)ytkownika w procesie wyboru miejsca przeznaczenia dla (cid:239)adunku z listy dost(cid:218)pnych miast musi istnie(cid:202) kod programu, który (1) rysuje element interfejsu u(cid:285)ytkownika na ekranie, (2) zadaje pytanie do bazy danych w celu uzyskania listy wszystkich mo(cid:285)- liwych miast, (3) odczytuje wybór u(cid:285)ytkownika i go sprawdza, (4) przy- pisuje wybrane miasto do (cid:239)adunku oraz (5) zapisuje wybór do bazy da- nych. Ca(cid:239)y ten kod nale(cid:285)y do jednego programu, lecz tylko jego ma(cid:239)a cz(cid:218)(cid:258)(cid:202) jest zwi(cid:200)zana z dziedzin(cid:200) logistyki morskiej. Programy wymagaj(cid:200) od projektu oraz kodu, aby obs(cid:239)ugiwa(cid:239)y wiele ró(cid:285)nych rodzajów zada(cid:241). Musz(cid:200) przecie(cid:285) pobiera(cid:202) dane od u(cid:285)ytkownika, wykonywa(cid:202) logik(cid:218) biznesow(cid:200), odwo(cid:239)ywa(cid:202) si(cid:218) do bazy danych, komuni- kowa(cid:202) przez sieci komputerowe, wy(cid:258)wietla(cid:202) informacje dla u(cid:285)ytkownika i tak dalej. Z tej przyczyny ilo(cid:258)(cid:202) kodu odpowiedzialnego za ka(cid:285)d(cid:200) funk- cjonalno(cid:258)(cid:202) programu mo(cid:285)e by(cid:202) znaczna. W programowaniu obiektowym kod obs(cid:239)uguj(cid:200)cy interfejs u(cid:285)ytkownika, baz(cid:218) danych, a tak(cid:285)e wykonuj(cid:200)cy inne czynno(cid:258)ci pomocnicze jest bardzo cz(cid:218)sto umieszczany bezpo(cid:258)rednio w obiek- tach biznesowych. Dodatkowa logika biznesowa jest równie(cid:285) 94 ROZDZIA(cid:146) 4. WYIZOLOWANIE DZIEDZINY Poleć książkęKup książkę umieszczona w kodzie interfejsów u(cid:285)ytkownika oraz skryptach bazodanowych. Dzieje si(cid:218) tak dlatego, i(cid:285) w krótkiej perspektywie jest to najprostszy sposób na utworzenie dzia(cid:239)aj(cid:200)cego kodu. W sytuacji, gdy kod zwi(cid:200)zany z dziedzin(cid:200) jest rozproszony w tak du(cid:285)ej ilo(cid:258)ci innego kodu, niezmiernie trudno jest go dojrze(cid:202) i zrozumie(cid:202). Pobie(cid:285)ne zmiany do interfejsu u(cid:285)ytkownika mog(cid:200) w rzeczywisto(cid:258)ci zmieni(cid:202) logik(cid:218) biznesow(cid:200). A zmiana regu(cid:239)y biz- nesowej mo(cid:285)e wymaga(cid:202) skrupulatnego (cid:258)ledzenia kodu obs(cid:239)uguj(cid:200)- cego interfejs u(cid:285)ytkownika, baz(cid:218) danych lub inne elementy pro- gramu. Implementacja spójnych obiektów sterowanych modelem staje si(cid:218) niepraktyczna, a testowanie automatyczne jest niewy- godne. Z powodu wszystkich tych technologii i logiki zaanga(cid:285)o- wanych w ka(cid:285)d(cid:200) czynno(cid:258)(cid:202) program musi albo by(cid:202) bardzo prosty, albo te(cid:285) stanie si(cid:218) praktycznie niemo(cid:285)liwy do zrozumienia. Tworzenie programów obs(cid:239)uguj(cid:200)cych bardzo z(cid:239)o(cid:285)one zadania wymaga rozdzielenia zagadnie(cid:241), umo(cid:285)liwiaj(cid:200)c tym samym samodzielne i wy(cid:239)(cid:200)czne skupienie si(cid:218) na ró(cid:285)nych cz(cid:218)(cid:258)ciach projektu. W tym samym czasie z(cid:239)o(cid:285)one interakcje w systemie musz(cid:200) by(cid:202) przeprowadzane z my(cid:258)l(cid:200) o utrzymaniu tej roz(cid:239)(cid:200)czno(cid:258)ci. Istnieje wiele sposobów podzia(cid:239)u systemu informatycznego, jednak do(cid:258)wiadczenie przemys(cid:239)owe pozwoli(cid:239)o utworzy(cid:202) i zdefiniowa(cid:202) ARCHI- TEKTURY WARSTWOWE, sk(cid:239)adaj(cid:200)ce si(cid:218) w szczególno(cid:258)ci z kilku ca(cid:239)kiem standardowych warstw. Metafora podzia(cid:239)u systemu na warstwy jest tak powszechnie stosowana, (cid:285)e dla wi(cid:218)kszo(cid:258)ci programistów wydaje si(cid:218) intu- icyjna. W literaturze dost(cid:218)pnych jest wiele dobrych dyskusji na temat podzia(cid:239)u systemów na warstwy. Niektóre z nich s(cid:200) nawet uj(cid:218)te w postaci wzorców (jak w ksi(cid:200)(cid:285)ce Buschmana1 z roku 1996 — strony 31 – 51). Podstawowa zasada stanowi, (cid:285)e dowolny element w danej warstwie jest zale(cid:285)ny jedynie od innych elementów w tej samej warstwie lub w war- stwach ni(cid:285)szych. Komunikacja w gór(cid:218) musi przechodzi(cid:202) przez mechanizm po(cid:258)redni, który zostanie omówiony nieco pó(cid:283)niej. Podstawow(cid:200) warto(cid:258)ci(cid:200) warstw jest fakt, i(cid:285) ka(cid:285)da z nich specjalizuje si(cid:218) w konkretnym aspekcie programu komputerowego. Ta specjalizacja umo(cid:285)liwia utworzenie bardziej spójnych projektów ka(cid:285)dego z nich, a co za tym idzie, projekty te s(cid:200) prostsze w interpretacji. Oczywi(cid:258)cie, niezmier- nie istotne jest wybieranie warstw, które b(cid:218)d(cid:200) zawiera(cid:202) najbardziej spójne i wa(cid:285)ne aspekty projektu. Z pomoc(cid:200) ponownie przychodz(cid:200) do(cid:258)wiadczenie 1 Frank Buschman jest wspó(cid:239)autorem ksi(cid:200)(cid:285)ki Pattern-Oriented Software Archi- tecture, opisuj(cid:200)cej szczegó(cid:239)owo zastosowanie wzorców w projektowaniu archi- tektury — przyp. t(cid:239)um. ARCHITEKTURA WARSTWOWA 95 Poleć książkęKup książkę oraz konwencje przemys(cid:239)owe. Chocia(cid:285) istnieje wiele typów warstw, to jednak najbardziej skuteczne architektury u(cid:285)ywaj(cid:200) pewnych odmian nast(cid:218)- puj(cid:200)cych czterech warstw poj(cid:218)ciowych: Warstwa interfejsu u(cid:285)ytkownika (lub prezentacji) Warstwa aplikacji Warstwa dziedziny (lub modelu) Warstwa infrastruktury Odpowiedzialna za wy(cid:258)wietlanie informacji dla u(cid:285)ytkownika oraz interpretacj(cid:218) jego polece(cid:241). Zamiast u(cid:285)ytkownika zewn(cid:218)trzny aktor mo(cid:285)e by(cid:202) niekiedy innym systemem komputerowym. Definiuje zamierzone zadania programu i steruje obiektami dziedziny w celu rozwi(cid:200)zania postawionych przed nimi zada(cid:241). Zadania, za które jest odpowiedzialna ta warstwa, s(cid:200) znacz(cid:200)ce dla biznesu i wymagane w celu poprawnego wspó(cid:239)dzia(cid:239)ania z warstwami aplikacji innych systemów. Warstwa jest utrzymywana w zwi(cid:218)z(cid:239)ej postaci. Nie zawiera regu(cid:239) ani wiedzy biznesowej, a jedynie zarz(cid:200)dza zadaniami i deleguje je do rozwi(cid:200)zania przez obiekty dziedzinowe w kolejnej warstwie ni(cid:285)ej. Warstwa nie musi odzwierciedla(cid:202) konkretnej sytuacji biznesowej, lecz mo(cid:285)e posiada(cid:202) stan, ukazuj(cid:200)cy post(cid:218)p zadania u(cid:285)ytkownikowi lub programowi. Warstwa odpowiedzialna za reprezentacj(cid:218) zagadnie(cid:241) biznesowych, informacji o sytuacji biznesowej oraz regu(cid:239) biznesowych. W tym miejscu jest przechowywany oraz u(cid:285)ywany stan odzwierciedlaj(cid:200)cy sytuacj(cid:218) biznesow(cid:200), chocia(cid:285) szczegó(cid:239)y techniczne zwi(cid:200)zane z przechowywaniem tego stanu s(cid:200) oddelegowane do warstwy infrastruktury. Ta warstwa stanowi istot(cid:218) programu od strony biznesowej. Udost(cid:218)pnia podstawowe mo(cid:285)liwo(cid:258)ci techniczne wspieraj(cid:200)ce warstwy wy(cid:285)sze, tj. komunikaty wysy(cid:239)ane do aplikacji, zachowywanie dziedziny, rysowanie elementów interfejsu u(cid:285)ytkownika itp. Warstwa infrastruktury mo(cid:285)e równie(cid:285) poprzez szkielet architektury wspiera(cid:202) wzorzec interakcji pomi(cid:218)dzy wszystkimi czterema warstwami. Niektóre projekty nie tworz(cid:200) ostrego podzia(cid:239)u pomi(cid:218)dzy warstwami interfejsu u(cid:285)ytkownika oraz aplikacji. Inne maj(cid:200) wiele warstw infrastruk- tury. Jednak to w(cid:239)a(cid:258)nie wydzielenie warstwy dziedziny jest istotne w celu umo(cid:285)liwienia stosowania PROJEKTU STEROWANEGO MODELEM. 96 ROZDZIA(cid:146) 4. WYIZOLOWANIE DZIEDZINY Poleć książkęKup książkę Dlatego: Podziel z(cid:239)o(cid:285)ony program na warstwy. Utwórz projekt ka(cid:285)- dej z nich, czyni(cid:200)c j(cid:200) zarazem spójn(cid:200), jak i zale(cid:285)n(cid:200) jedynie od warstw po(cid:239)o(cid:285)onych ni(cid:285)ej. Aby utrzyma(cid:202) lu(cid:283)ne powi(cid:200)zanie z wy(cid:285)- szymi warstwami, stosuj standardowe wzorce architektoniczne. Umie(cid:258)(cid:202) kod zwi(cid:200)zany z modelem dziedziny w pojedynczej war- stwie i odizoluj go od kodu interfejsu u(cid:285)ytkownika, aplikacji oraz infrastruktury. Dzi(cid:218)ki takiemu podej(cid:258)ciu obiekty dziedziny, pozba- wione konieczno(cid:258)ci obs(cid:239)ugi wy(cid:258)wietlania, przechowywania, zarz(cid:200)- dzania zadaniami aplikacji itd., mog(cid:200) skoncentrowa(cid:202) si(cid:218) jedynie na wyra(cid:285)eniu modelu dziedziny. To umo(cid:285)liwia wzbogacenie i uproszczenie modelu na tyle, aby móg(cid:239) on wychwyci(cid:202) wiedz(cid:218) biznesow(cid:200) i wykorzysta(cid:202) j(cid:200) w praktyce. Oddzielenie warstwy dziedziny od warstw infrastruktury oraz inter- fejsu u(cid:285)ytkownika umo(cid:285)liwia utworzenie bardziej przejrzystego projektu ka(cid:285)dej z nich. Utrzymanie wyizolowanych warstw jest zdecydowanie mniej kosztowne, poniewa(cid:285) s(cid:200) one rozwijane we w(cid:239)asnym tempie i odpowia- daj(cid:200) na ró(cid:285)ne w(cid:239)asne potrzeby. Podzia(cid:239) na warstwy pomaga równie(cid:285) we wdro(cid:285)eniu systemu rozproszonego, pozwalaj(cid:200)c na umieszczenie poszcze- gólnych warstw na ró(cid:285)nych serwerach oraz klientach w celu zmniejsze- nia narzutu komunikacyjnego i zwi(cid:218)kszenia wydajno(cid:258)ci (Fowler 1996). Przyk(cid:239)ad Podzia(cid:239) na warstwy w przypadku funkcjonalno(cid:258)ci internetowej systemu bankowego Aplikacja udost(cid:218)pnia szereg funkcjonalno(cid:258)ci zarz(cid:200)dzania kontami banko- wymi. Jedn(cid:200) z nich jest przelew (cid:258)rodków, gdzie u(cid:285)ytkownik podaje numery dwóch rachunków oraz kwot(cid:218), a nast(cid:218)pnie zatwierdza przelew. Aby ten przyk(cid:239)ad by(cid:239)o (cid:239)atwiej zrozumie(cid:202), pomin(cid:218) wi(cid:218)kszo(cid:258)(cid:202) tech- nicznych aspektów, a w szczególno(cid:258)ci zabezpieczenia. Projekt dziedziny zostanie równie(cid:285) uproszczony (rzeczywista z(cid:239)o(cid:285)ono(cid:258)(cid:202) zwi(cid:218)kszy(cid:239)aby jedynie potrzeb(cid:218) posiadania architektury warstwowej). Co wi(cid:218)cej, ta konkretna infrastruktura zaprezentowana w tym przyk(cid:239)adzie mia(cid:239)a w zamierzeniu by(cid:202) prosta oraz oczywista, co dotyczy(cid:202) mia(cid:239)o równie(cid:285) samego przyk(cid:239)adu — nie jest to (cid:285)aden sugerowany projekt. Odpowiedzialno(cid:258)ci zwi(cid:200)zane z pozo- sta(cid:239)ymi funkcjonalno(cid:258)ciami systemu b(cid:218)d(cid:200) podzielone na warstwy w sposób przedstawiony na rysunku 4.1. Zauwa(cid:285), (cid:285)e to warstwa dziedziny, a nie warstwa aplikacji jest odpowie- dzialna za podstawowe regu(cid:239)y biznesowe — w tym przypadku regu(cid:239)a mówi: „Ka(cid:285)de uznanie na rachunku musi mie(cid:202) odpowiadaj(cid:200)ce mu obci(cid:200)(cid:285)enie”. ARCHITEKTURA WARSTWOWA 97 Poleć książkęKup książkę Rysunek 4.1. Obiekty wype(cid:239)niaj(cid:200) odpowiedzialno(cid:258)ci zgodne z warstw(cid:200), do której przynale(cid:285)(cid:200), i s(cid:200) bardziej zwi(cid:200)zane z innymi obiektami w tej samej warstwie Aplikacja nie czyni (cid:285)adnych za(cid:239)o(cid:285)e(cid:241) co do (cid:283)ród(cid:239)a pochodzenia (cid:285)(cid:200)dania przelewu. Interfejs u(cid:285)ytkownika zawiera(cid:202) b(cid:218)dzie prawdopodobnie pola do wprowadzania numerów kont oraz warto(cid:258)ci przelewu, a tak(cid:285)e przyciski odpowiedzialne za wydawanie polece(cid:241). Móg(cid:239)by on jednak — bez wp(cid:239)ywu na warstw(cid:218) aplikacji oraz jak(cid:200)kolwiek z ni(cid:285)szych warstw — zosta(cid:202) zast(cid:200)piony (cid:285)(cid:200)daniem przelewu w postaci dokumentu XML. Takie rozdzielenie warstw wyst(cid:218)puje nie dlatego, (cid:285)e w projektach interfejsy u(cid:285)ytkowników s(cid:200) cz(cid:218)sto zast(cid:218)powane dokumentami XML, lecz dlatego, (cid:285)e spójne rozdzielenie zada(cid:241) czyni projekt ka(cid:285)dej warstwy (cid:239)atwym do zrozumienia i utrzymania. W rzeczywisto(cid:258)ci sam rysunek 4.1 jedynie w sposób umiarkowany ilustruje problem braku izolacji dziedziny. Poniewa(cid:285) musia(cid:239) on obejmowa(cid:202) wszystko, pocz(cid:200)wszy od (cid:285)(cid:200)dania przelewu, do nadzorowania transakcji, warstwa dziedziny musi zosta(cid:202) uproszczona w taki sposób, aby ca(cid:239)a inter- akcja z systemem by(cid:239)a do(cid:258)(cid:202) prosta do zrozumienia. Gdyby(cid:258)my skoncen- trowali si(cid:218) na projekcie wyizolowanej warstwy dziedziny, zostawiliby(cid:258)my miejsce na stronie oraz w naszych g(cid:239)owach na model, który w lepszy sposób reprezentowa(cid:239)by regu(cid:239)y tej dziedziny. By(cid:202) mo(cid:285)e do(cid:239)(cid:200)czyliby(cid:258)my pe(cid:239)n(cid:200) rachunkowo(cid:258)(cid:202), obiekty obci(cid:200)(cid:285)e(cid:241) i uzna(cid:241) rachunków albo te(cid:285) obiekty reprezentuj(cid:200)ce transakcje pieni(cid:218)(cid:285)ne. 98 ROZDZIA(cid:146) 4. WYIZOLOWANIE DZIEDZINY Poleć książkęKup książkę Powi(cid:200)zanie warstw Jak dot(cid:200)d nasza dyskusja skupia(cid:239)a si(cid:218) na rozdzieleniu warstw oraz na tym, w jaki sposób partycjonowanie ulepsza projekt ka(cid:285)dego aspektu programu, w szczególno(cid:258)ci warstwy dziedziny. Jednak warstwy, oczywi(cid:258)cie, musz(cid:200) by(cid:202) ze sob(cid:200) po(cid:239)(cid:200)czone. Wykonanie takiego po(cid:239)(cid:200)czenia bez utraty korzy(cid:258)ci wynikaj(cid:200)cych z ich rozdzielenia le(cid:285)y u podstaw wielu wzorców. Warstwy maj(cid:200) by(cid:202) lu(cid:283)no zwi(cid:200)zane, a zale(cid:285)no(cid:258)ci projektowe musz(cid:200) by(cid:202) tylko jednokierunkowe. Warstwy wy(cid:285)sze mog(cid:200) w prosty sposób u(cid:285)ywa(cid:202) elementów warstw ni(cid:285)szych poprzez wykorzystanie ich interfejsów publicz- nych, przechowuj(cid:200)c odwo(cid:239)ania do nich (cho(cid:202)by tymczasowo) — ogólnie rzecz bior(cid:200)c, u(cid:285)ywaj(cid:200)c standardowych sposobów komunikacji. Jednak(cid:285)e w przypadku, gdy obiekt warstwy ni(cid:285)szej potrzebuje skomunikowa(cid:202) si(cid:218) w gór(cid:218) (nie mówimy o zwyk(cid:239)ej odpowiedzi na zapytanie), musimy skorzy- sta(cid:202) z innego mechanizmu, u(cid:285)ywaj(cid:200)c w tym celu wzorca architektonicz- nego do (cid:239)(cid:200)czenia warstw w rodzaju odwo(cid:239)a(cid:241) zwrotnych (callbacks) albo OBSERWATORÓW (patrz Gamma 1995 r.). Dziadkiem wszystkich wzorców u(cid:285)ywanych do (cid:239)(cid:200)czenia interfejsu u(cid:285)ytkownika z warstwami aplikacji oraz dziedziny jest MODEL-WIDOK- -KONTROLER (ang. model-view-controler — MVC). Wzorzec ten zosta(cid:239) zapocz(cid:200)tkowany w okresie (cid:258)wietno(cid:258)ci Smalltalka w latach 70. ubieg(cid:239)ego wieku i zainspirowa(cid:239) wiele pó(cid:283)niejszych architektur interfejsu u(cid:285)ytkow- nika. Wraz ze swoimi wieloma przydatnymi odmianami zosta(cid:239) on omó- wiony przez Fowlera (2003 r.). Równie(cid:285) Larman (1998 r.) sprawdza(cid:239) ten temat we WZORCU ROZDZIELENIA MODELU-WIDOKU, a opra- cowany przez niego KOORDYNATOR APLIKACJI jest jednym z podej(cid:258)(cid:202) stosowanych do po(cid:239)(cid:200)czenia z warstw(cid:200) aplikacji. Oczywi(cid:258)cie, istniej(cid:200) inne style (cid:239)(cid:200)czenia interfejsu u(cid:285)ytkownika z apli- kacj(cid:200). Do naszych zastosowa(cid:241) wszystkie z nich b(cid:218)d(cid:200) poprawne, o ile b(cid:218)d(cid:200) zachowywa(cid:202) izolacj(cid:218) warstwy dziedziny, pozwalaj(cid:200)c projektowa(cid:202) obiekty dziedziny bez jednoczesnego przejmowania si(cid:218) interfejsem u(cid:285)ytkownika, który móg(cid:239)by ich pó(cid:283)niej u(cid:285)ywa(cid:202). Warstwa infrastruktury nie inicjuje zazwyczaj (cid:285)adnych akcji w war- stwie dziedziny. Istniej(cid:200)c „poni(cid:285)ej” warstwy dziedziny, nie powinna ona posiada(cid:202) (cid:285)adnej konkretnej wiedzy o dziedzinie, której s(cid:239)u(cid:285)y. Rzeczywi(cid:258)cie tego rodzaju techniczne mo(cid:285)liwo(cid:258)ci s(cid:200) bardzo cz(cid:218)sto udost(cid:218)pniane w cha- rakterze US(cid:146)UG. Je(cid:285)eli na przyk(cid:239)ad aplikacja chce wys(cid:239)a(cid:202) wiadomo(cid:258)(cid:202) e-mail, wtedy w warstwie infrastruktury mo(cid:285)e zosta(cid:202) zlokalizowany inter- fejs s(cid:239)u(cid:285)(cid:200)cy do wysy(cid:239)ania wiadomo(cid:258)ci, za(cid:258) elementy warstwy aplikacji mog(cid:239)yby tylko za(cid:285)(cid:200)da(cid:202) jej wys(cid:239)ania. Tego rodzaju rozdzielenie daje dodat- kow(cid:200) wielofunkcyjno(cid:258)(cid:202). Interfejs do wysy(cid:239)ania wiadomo(cid:258)ci móg(cid:239)by zosta(cid:202) ARCHITEKTURA WARSTWOWA 99 Poleć książkęKup książkę po(cid:239)(cid:200)czony z serwerem pocztowym, faksowym lub dowolnym innym aktu- alnie dost(cid:218)pnym. Jednak najwa(cid:285)niejsza korzy(cid:258)(cid:202) zwi(cid:200)zana jest z uprosz- czeniem warstwy aplikacji, która jest w(cid:200)sko skoncentrowana na swoim zadaniu i wie, kiedy ma wys(cid:239)a(cid:202) wiadomo(cid:258)(cid:202), lecz nie przejmuje si(cid:218) tym, w jaki sposób to wykona(cid:202). Warstwy aplikacji oraz dziedziny polegaj(cid:200) na US(cid:146)UGACH dostar- czanych przez warstw(cid:218) infrastruktury. Je(cid:285)eli tylko zakres US(cid:146)UGI zosta(cid:239) poprawnie wybrany, a jej interfejs prawid(cid:239)owo zaprojektowany, wtedy obiekt wywo(cid:239)uj(cid:200)cy mo(cid:285)e pozosta(cid:202) lu(cid:283)no zwi(cid:200)zany, bez uwzgl(cid:218)dniania skomplikowanej logiki kryj(cid:200)cej si(cid:218) pod interfejsem US(cid:146)UGI. Jednak nie ca(cid:239)a infrastruktura przykryta jest US(cid:146)UGAMI mo(cid:285)liwymi do wywo(cid:239)ania z warstw wy(cid:285)szych. Niektóre komponenty techniczne s(cid:200) zaprojektowane tak, aby w bezpo(cid:258)redni sposób wspiera(cid:202) podstawowe funkcje innych warstw (na przyk(cid:239)ad poprzez udost(cid:218)pnienie abstrakcyj- nych klas bazowych dla obiektów dziedziny) oraz dostarcza(cid:202) mechanizm do ich powi(cid:200)zania (na przyk(cid:239)ad implementacje wzorca MVC i podobnych). Tego rodzaju „szkielet architektury” ma zdecydowanie wi(cid:218)kszy wp(cid:239)yw na projekt innych cz(cid:218)(cid:258)ci programu. Szkielety architektury W sytuacji, gdy infrastruktura udost(cid:218)pniana jest w postaci US(cid:146)UG wywo- (cid:239)ywanych przez interfejsy, zrozumienie podzia(cid:239)u na warstwy oraz sposobu ich utrzymania w sposób lu(cid:283)no zwi(cid:200)zany ze sob(cid:200) jest do(cid:258)(cid:202) intuicyjne. Jednak niektóre problemy techniczne wymagaj(cid:200) bardziej zach(cid:239)annej formy infrastruktury. Struktury integruj(cid:200)ce wiele potrzeb zwi(cid:200)zanych z infra- struktur(cid:200) wymagaj(cid:200) cz(cid:218)sto, aby inne warstwy by(cid:239)y zaimplementowane w okre(cid:258)lony sposób, na przyk(cid:239)ad jako podklasa klasy szkieletowej lub z uporz(cid:200)dkowanymi sygnaturami metod (wydawa(cid:202) by si(cid:218) mog(cid:239)o bardzo nieintuicyjne, aby podklasa by(cid:239)a w warstwie wy(cid:285)szej ni(cid:285) klasa nadrz(cid:218)dna, ale miejmy na uwadze, która z klas zawiera wi(cid:218)cej wiedzy o drugiej). Najlepszy szkielet architektury rozwi(cid:200)zuje z(cid:239)o(cid:285)one problemy techniczne, pozwalaj(cid:200)c programi(cid:258)cie zajmuj(cid:200)cemu si(cid:218) dziedzin(cid:200) skoncentrowa(cid:202) si(cid:218) na wyra(cid:285)eniu modelu. Niemniej jednak szkielet ten mo(cid:285)e tak(cid:285)e stan(cid:200)(cid:202) na drodze programisty, tworz(cid:200)c na przyk(cid:239)ad zbyt wiele za(cid:239)o(cid:285)e(cid:241) ograniczaj(cid:200)- cych wybór projektu dziedziny lub te(cid:285) tak ci(cid:218)(cid:285)k(cid:200) implementacj(cid:218), (cid:285)e b(cid:218)dzie to opó(cid:283)nia(cid:202) programowanie. Pewnego rodzaju szkielet architektury jest zazwyczaj niezb(cid:218)dny (cho- cia(cid:285) niekiedy zespo(cid:239)y wybieraj(cid:200) taki, który niezbyt dobrze im s(cid:239)u(cid:285)y). W trak- cie stosowania szkieletu zespó(cid:239) musi skoncentrowa(cid:202) si(cid:218) na swoim zadaniu, czyli stworzeniu implementacji wyra(cid:285)aj(cid:200)cej model dziedziny, którego u(cid:285)ywa 100 ROZDZIA(cid:146) 4. WYIZOLOWANIE DZIEDZINY Poleć książkęKup książkę do rozwi(cid:200)zania wa(cid:285)nych problemów. To w(cid:239)a(cid:258)nie zespó(cid:239) musi zaadapto- wa(cid:202) szkielet, nawet je(cid:285)eli b(cid:218)dzie to oznacza(cid:202) pomini(cid:218)cie pewnych jego funkcjonalno(cid:258)ci. Na przyk(cid:239)ad wczesne aplikacje J2EE bardzo cz(cid:218)sto imple- mentowa(cid:239)y wszystkie obiekty dziedziny w postaci „ziaren encyjnych” (ang. entity beans). Takie podej(cid:258)cie wp(cid:239)ywa(cid:239)o negatywnie zarówno na wydajno(cid:258)(cid:202), jak i tempo programowania. Obecn(cid:200) praktyk(cid:200) jest raczej zasto- sowanie szkieletu J2EE do wi(cid:218)kszych obiektów oraz implementacja wi(cid:218)kszo(cid:258)ci logiki biznesowej przy u(cid:285)yciu prostych obiektów Javy. Wiele ogranicze(cid:241) szkieletu architektury mo(cid:285)e by(cid:202) zminimalizowanych poprzez selektywne zastosowanie go do rozwi(cid:200)zania trudnych problemów, bez poszukiwania cudownego rozwi(cid:200)zania na wszystkie bol(cid:200)czki. Rozs(cid:200)dne stosowanie tylko wybranych, najbardziej warto(cid:258)ciowych cz(cid:218)(cid:258)ci rozwi(cid:200)- zania zmniejsza zwi(cid:200)zanie implementacji ze szkieletem architektury, co daje wi(cid:218)ksz(cid:200) elastyczno(cid:258)(cid:202) w pó(cid:283)niejszych decyzjach projektowych. Bior(cid:200)c pod uwag(cid:218), jak bardzo skomplikowanych jest wiele z obecnie dost(cid:218)pnych szkieletów aplikacji, podej(cid:258)cie minimalistyczne w ich stosowaniu pomaga utrzyma(cid:202) obiekty biznesowe w przejrzystej i wymownej postaci. Szkielety architektury oraz inne narz(cid:218)dzia wspomagaj(cid:200)ce b(cid:218)d(cid:200) wci(cid:200)(cid:285) rozwijane. Nowsze z nich b(cid:218)d(cid:200) automatyzowa(cid:202) i dostarcza(cid:202) wzorce dla coraz to wi(cid:218)kszej liczby aspektów technicznych aplikacji. Je(cid:285)eli tylko zostan(cid:200) one poprawnie zastosowane, programi(cid:258)ci aplikacji b(cid:218)d(cid:200) mogli w coraz wi(cid:218)kszym stopniu koncentrowa(cid:202) si(cid:218) na modelowaniu podsta- wowych problemów biznesowych, co zwi(cid:218)kszy produktywno(cid:258)(cid:202) zespo(cid:239)u oraz jako(cid:258)(cid:202) pracy. Wybieraj(cid:200)c takie podej(cid:258)cie, musimy wystrzega(cid:202) si(cid:218) nad- miernego optymizmu w stosunku do gotowych rozwi(cid:200)za(cid:241) technicznych — bardzo rozwlek(cid:239)e szkielety mog(cid:200) równie(cid:285) ogranicza(cid:202) programistów. To w warstwie dziedziny (cid:285)yje model W wi(cid:218)kszo(cid:258)ci dzisiejszych systemów stosowana jest ARCHITEKTURA WARSTWOWA, która u(cid:285)ywa wielu odmian podej(cid:258)cia do podzia(cid:239)u na war- stwy. Równie(cid:285) wiele ró(cid:285)nych stylów programowania mo(cid:285)e skorzysta(cid:202) z takiego podzia(cid:239)u. Niemniej jednak projekt sterowany dziedzin(cid:200) wymaga istnienia tylko jednej konkretnej warstwy. Model dziedziny jest zestawem poj(cid:218)(cid:202). Wyrazem modelu oraz wszyst- kich zwi(cid:200)zanych z nim bezpo(cid:258)rednio elementów dziedziny jest „warstwa dziedziny”. Sk(cid:239)adaj(cid:200) si(cid:218) na ni(cid:200) dziedzina oraz implementacja logiki bizne- sowej. W PROJEKCIE STEROWANYM MODELEM struktury programu uzyskane w warstwie dziedziny odzwierciedlaj(cid:200) poj(cid:218)cia tego modelu. TO W WARSTWIE DZIEDZINY (cid:191)YJE MODEL 101 Poleć książkęKup książkę Sytuacja, w której logika dziedziny jest wymieszana z innym kodem programu, nie jest zbyt praktyczna. Wyizolowanie dziedziny w procesie jej implementacji jest warunkiem wst(cid:218)pnym dla projektu sterowanego dziedzin(cid:200). Antywzorzec inteligentnego interfejsu u(cid:285)ytkownika Tak w(cid:239)a(cid:258)nie wygl(cid:200)da powszechnie akceptowany wzorzec ARCHITEK- TURY WARSTWOWEJ dla aplikacji obiektowych. Wprawdzie bardzo cz(cid:218)sto próbuje si(cid:218) rozdzia(cid:239)u interfejsu u(cid:285)ytkownika od aplikacji oraz dzie- dziny, jednak zbyt rzadko jest on w pe(cid:239)ni osi(cid:200)galny. Dlatego odst(cid:218)pstwa od tego wzorca wymagaj(cid:200) odr(cid:218)bnej dyskusji. Wiele projektów informatycznych podejmuje prób(cid:218) stosowania znacz- nie mniej wyszukanego podej(cid:258)cia projektowego, nazywanego przeze mnie INTELIGENTNYM INTERFEJSEM U(cid:191)YTKOWNIKA. Jest to jednak tylko alternatywna, roz(cid:239)(cid:200)czna odnoga w rozwoju, niezgodna z podej(cid:258)ciem wymaganym przez projektowanie sterowane dziedzin(cid:200). Je(cid:285)eli kto(cid:258) pójdzie t(cid:200) drog(cid:200), wi(cid:218)kszo(cid:258)(cid:202) tre(cid:258)ci tej ksi(cid:200)(cid:285)ki nie b(cid:218)dzie mo(cid:285)liwa do zastosowania. Najcz(cid:218)(cid:258)ciej interesuj(cid:200) mnie sytuacje, w których wzorzec INTELIGENT- NEGO INTERFEJSU U(cid:191)YTKOWNIKA nie powinien by(cid:202) stosowany, dlatego z przek(cid:200)sem nazywam go „antywzorcem”. Omówienie go w tym miejscu b(cid:218)dzie przydatnym orze(cid:283)wieniem i pomo(cid:285)e we wskazaniu przy- czyn, które w dalszej cz(cid:218)(cid:258)ci tej ksi(cid:200)(cid:285)ki decyduj(cid:200) o wyborze trudniejszej (cid:258)cie(cid:285)ki projektowania. * * * Projekt ma za zadanie dostarczy(cid:202) prost(cid:200) funkcjonalno(cid:258)(cid:202), zdomino- wan(cid:200) przez wprowadzanie oraz wy(cid:258)wietlanie danych, z jedynie kilkoma regu(cid:239)ami biznesowymi. W sk(cid:239)ad zespo(cid:239)u projektowego nie wchodz(cid:200) osoby z du(cid:285)ym do(cid:258)wiadczeniem w modelowaniu obiektowym. W przypadku, gdy niedo(cid:258)wiadczony zespól pracuj(cid:200)cy nad prostym projektem zdecyduje si(cid:218) wypróbowa(cid:202) PROJEKTOWANIE STEROWANE MODELEM z ARCHITEKTUR(cid:107) WARSTWOW(cid:107), stanie przed konieczno(cid:258)ci(cid:200) podj(cid:218)cia szybkiej i wymagaj(cid:200)cej nauki. Cz(cid:239)onkowie zespo(cid:239)u b(cid:218)d(cid:200) zmuszeni opanowa(cid:202) zaawansowane nowe technologie oraz da(cid:202) sobie rad(cid:218) z nauk(cid:200) modelowania obiektowego (co jest wyzwaniem nawet z pomoc(cid:200) tej ksi(cid:200)(cid:285)ki). 102 ROZDZIA(cid:146) 4. WYIZOLOWANIE DZIEDZINY Poleć książkęKup książkę Narzut spowodowany przez zarz(cid:200)dzanie infrastruktur(cid:200) oraz wszystkimi warstwami spowoduje wyd(cid:239)u(cid:285)enie prostych zada(cid:241). Proste projekty maj(cid:200) zazwyczaj krótkie terminy i (cid:258)rednio skom- plikowane oczekiwania. Projekt zostanie z pewno(cid:258)ci(cid:200) przerwany, na d(cid:239)ugo zanim zespó(cid:239) doko(cid:241)czy przypisane do(cid:241) zadania, nie maj(cid:200)c szans na zaprezentowanie wspania(cid:239)ych mo(cid:285)liwo(cid:258)ci zastosowa- nego podej(cid:258)cia. Nawet je(cid:285)eli zespó(cid:239) b(cid:218)dzie mie(cid:202) wi(cid:218)cej czasu, to bez pomocy eksperta cz(cid:239)onkowie zespo(cid:239)u prawdopodobnie nie dadz(cid:200) rady opa- nowa(cid:202) wymaganych technik. Je(cid:285)eli nawet na koniec pokonaj(cid:200) te wszystkie przeciwno(cid:258)ci, to i tak w ko(cid:241)cu utworz(cid:200) prosty system, w którym nigdy nie b(cid:218)d(cid:200) wymagane bogate funkcjonalno(cid:258)ci. Bardziej do(cid:258)wiadczone zespo(cid:239)y nie b(cid:218)d(cid:200) musia(cid:239)y i(cid:258)(cid:202) na takie kom- promisy. Oczywi(cid:258)cie, wieloletni programi(cid:258)ci mogliby skróci(cid:202) czas potrzebny na nauk(cid:218) i zarz(cid:200)dzanie warstwami. Projektowanie sterowane dziedzin(cid:200) sprawdza si(cid:218) najlepiej w przypadku ambitnych projektów i b(cid:218)dzie wyma- ga(cid:202) du(cid:285)ych umiej(cid:218)tno(cid:258)ci programistycznych. Nie wszystkie projekty s(cid:200) ambitne i nie wszystkie zespo(cid:239)y projektowe mog(cid:200) opanowa(cid:202) wymagane umiej(cid:218)tno(cid:258)ci. Dlatego je(cid:285)eli tylko pozwalaj(cid:200) na to okoliczno(cid:258)ci: Umie(cid:258)(cid:202) ca(cid:239)(cid:200) logik(cid:218) biznesow(cid:200) w interfejsie u(cid:285)ytkownika. Podziel aplikacj(cid:218) na ma(cid:239)e funkcje i zaimplementuj je jako oddzielne modu(cid:239)y interfejsu, umieszczaj(cid:200)c w nich regu(cid:239)y bizne- sowe. Wykorzystaj baz(cid:218) danych w charakterze wspó(cid:239)dzielonego repozytorium danych. U(cid:285)yj najbardziej zautomatyzowanych narz(cid:218)dzi do tworzenia interfejsu u(cid:285)ytkownika oraz programowa- nia wizualnego, jakie tylko s(cid:200) dost(cid:218)pne na rynku. Herezja! Przecie(cid:285) dobra nowina mówi (i jest g(cid:239)oszona wsz(cid:218)dzie, równie(cid:285) w tej ksi(cid:200)(cid:285)ce), (cid:285)e dziedzina powinna by(cid:202) oddzielona od interfejsu u(cid:285)ytkownika. W rzeczywisto(cid:258)ci bez tego rozdzielenia trudno b(cid:218)dzie zaim- plementowa(cid:202) jak(cid:200)kolwiek metod(cid:218) omawian(cid:200) w tej ksi(cid:200)(cid:285)ce, dlatego te(cid:285) wzorzec INTELIGENTNEGO INTERFEJSU U(cid:191)YTKOWNIKA w kon- tek(cid:258)cie projektowania sterowanego dziedzin(cid:200) mo(cid:285)e by(cid:202) traktowany jako „antywzorzec”. Jednak w niektórych sytuacjach skorzystanie z tego wzorca jest uprawnione. Mówi(cid:200)c szczerze, ma on pewne zalety i w niektórych okoliczno(cid:258)ciach mo(cid:285)e sprawdza(cid:202) si(cid:218) najlepiej — co cz(cid:218)(cid:258)ciowo t(cid:239)umaczy, dlaczego jest tak popularny. Omówienie go w tym miejscu pomo(cid:285)e zro- zumie(cid:202), dlaczego musimy oddziela(cid:202) warstw(cid:218) aplikacji od dziedziny i, co wi(cid:218)cej, w jakich sytuacjach mogliby(cid:258)my nie chcie(cid:202) tego robi(cid:202). ANTYWZORZEC INTELIGENTNEGO INTERFEJSU U(cid:191)YTKOWNIKA 103 Poleć książkęKup książkę Zalety: (cid:120) Dost(cid:218)pna od razu du(cid:285)a wydajno(cid:258)(cid:202) dla prostych aplikacji. (cid:120) Mniej do(cid:258)wiadczeni programi(cid:258)ci mog(cid:200) u(cid:285)ywa(cid:202) tego wzorca po pobie(cid:285)nym przeszkoleniu. (cid:120) Nawet braki w wymaganiach mog(cid:200) zosta(cid:202) rozwi(cid:200)zane po udost(cid:218)pnieniu prototypu u(cid:285)ytkownikom, a nast(cid:218)pnie szybkim zaadaptowaniu go do ich potrzeb. (cid:120) Aplikacje s(cid:200) od siebie oddzielone, wi(cid:218)c harmonogram dostarczania ma(cid:239)ych modu(cid:239)ów mo(cid:285)e by(cid:202) opracowany z do(cid:258)(cid:202) du(cid:285)(cid:200) dok(cid:239)adno(cid:258)ci(cid:200). Rozszerzenie sytemu o dodatkowe proste funkcjonalno(cid:258)ci mo(cid:285)e by(cid:202) (cid:239)atwe. (cid:120) Z tym wzorcem dobrze wspó(cid:239)pracuj(cid:200) bazy danych, które umo(cid:285)liwiaj(cid:200) integracj(cid:218) na poziomie danych. (cid:120) Dobra wspó(cid:239)praca z narz(cid:218)dziami 4GL. (cid:120) Po udost(cid:218)pnieniu aplikacji osoby j(cid:200) utrzymuj(cid:200)ce b(cid:218)d(cid:200) w stanie szybko zmieni(cid:202) jej cz(cid:218)(cid:258)ci, nawet te, których nie b(cid:218)d(cid:200) w stanie zrozumie(cid:202). Ewentualne efekty zmian b(cid:218)d(cid:200) mie(cid:202) tylko lokalny wp(cid:239)yw na konkretny fragment interfejsu u(cid:285)ytkownika. Wady: (cid:120) Integracja aplikacji jest trudna, o ile nie jest zrobiona poprzez baz(cid:218) danych. (cid:120) Nie wyst(cid:218)puje wspó(cid:239)dzielenie kodu oraz nie ma (cid:285)adnego modelu abstrakcyjnego logiki biznesowej. Regu(cid:239)y biznesowe musz(cid:200) by(cid:202) duplikowane w ka(cid:285)dej operacji, której dotycz(cid:200). (cid:120) Szybkie prototypowanie oraz przeróbki kodu maj(cid:200) swoje naturalne ograniczenia, poniewa(cid:285) brak abstrakcji dziedziny ogranicza mo(cid:285)liwo(cid:258)ci zmian. (cid:120) Z(cid:239)o(cid:285)ono(cid:258)(cid:202) szybko oka(cid:285)e si(cid:218) ograniczeniem nie do przezwyci(cid:218)(cid:285)enia. Dlatego naturaln(cid:200) (cid:258)cie(cid:285)k(cid:200) rozwoju b(cid:218)dzie tworzenie kolejnych prostych aplikacji. Nie ma prostej recepty na wzbogacanie istniej(cid:200)cej logiki. W przypadku (cid:258)wiadomego zastosowania tego wzorca zespó(cid:239) mo(cid:285)e unikn(cid:200)(cid:202) du(cid:285)ego narzutu pracy zwi(cid:200)zanej z innymi podej(cid:258)ciami. Cz(cid:218)st(cid:200) pomy(cid:239)k(cid:200) jest podejmowanie si(cid:218) korzystania ze z(cid:239)o(cid:285)onego podej(cid:258)cia do projektowania w sytuacji, gdy zespó(cid:239) nie jest gotów kontynuowa(cid:202) go na ca(cid:239)ej (cid:258)cie(cid:285)ce projektu. Kolejnym cz(cid:218)sto pope(cid:239)nianym b(cid:239)(cid:218)dem jest tworzenie z(cid:239)o(cid:285)onej warstwy infrastrukturalnej i korzystanie z najlepszych narz(cid:218)dzi na rynku w projekcie, który w(cid:239)a(cid:258)ciwie tego nie potrzebuje. 104 ROZDZIA(cid:146) 4. WYIZOLOWANIE DZIEDZINY Poleć książkęKup książkę U(cid:285)ycie wi(cid:218)kszo(cid:258)ci uniwersalnych j(cid:218)zyków (takich jak Java) w przy- padku tych aplikacji b(cid:218)dzie stanowi(cid:202) do(cid:258)(cid:202) du(cid:285)(cid:200) przesad(cid:218) i b(cid:218)dzie bardzo kosztowne. W takiej sytuacji skorzystanie z rozwi(cid:200)za(cid:241) 4GL b(cid:218)dzie najlep- szym sposobem. Nale(cid:285)y jednak pami(cid:218)ta(cid:202), i(cid:285) konsekwencj(cid:200) wyboru tego wzorca jest utrudniona migracja do innego podej(cid:258)cia projektowego — wybór ogra- nicza si(cid:218) w(cid:239)a(cid:258)ciwie do zast(cid:200)pienia ca(cid:239)ych aplikacji nowymi. Samo u(cid:285)y- cie j(cid:218)zyków programowania ogólnego przeznaczenia, w rodzaju Javy, nie umo(cid:285)liwi w przysz(cid:239)o(cid:258)ci (cid:239)atwego porzucenia wzorca INTELIGENTNEGO INTERFEJSU U(cid:191)YTKOWNIKA. Je(cid:285)eli wi(cid:218)c wybra(cid:239)e(cid:258) t(cid:218) drog(cid:218), powi- niene(cid:258) równie(cid:285) dostosowa(cid:202) swoje narz(cid:218)dzia. Nie próbuj si(cid:218) asekurowa(cid:202). Z samego zastosowania uniwersalnego j(cid:218)zyka nie b(cid:218)dzie wynika(cid:202) elastycz- no(cid:258)(cid:202) systemu. Mo(cid:285)e si(cid:218) to jednak sko(cid:241)czy(cid:202) zwi(cid:218)kszeniem kosztów. Analogicznie zespó(cid:239), który wybra(cid:239) drog(cid:218) PROJEKTOWANIA STE- ROWANEGO MODELEM, powinien dostosowa(cid:202) swój projekt od samego pocz(cid:200)tku. Oczywi(cid:258)cie, nawet bardzo do(cid:258)wiadczone, ambitne zespo(cid:239)y pro- jektowe musz(cid:200) rozpocz(cid:200)(cid:202) od prostej funkcjonalno(cid:258)ci i rozwija(cid:202) sw(cid:200) prac(cid:218) w kolejnych etapach. Jednak(cid:285)e te pierwsze czynno(cid:258)ci musz(cid:200) by(cid:202) STE- ROWANE MODELEM z wydzielon(cid:200) warstw(cid:200) dziedziny, gdy(cid:285) w prze- ciwnym razie projekt prawdopodobnie sko(cid:241)czy na podej(cid:258)ciu wykorzystu- j(cid:200)cym INTELIGENTNY INTERFEJS U(cid:191)YTKOWNIKA. * * * Wzorzec INTELIGENTNEGO INTERFEJSU U(cid:191)YTKOWNIKA zo- sta(cid:239) tutaj omówiony jedynie po to, aby wyja(cid:258)ni(cid:202) przyczyny sytuacji, w których wzorzec ARCHITEKTURY WARSTWOWEJ jest niezb(cid:218)dny do wyizolowania warstwy dziedziny. Oczywi(cid:258)cie, istniej(cid:200) inne rozwi(cid:200)zania, le(cid:285)(cid:200)ce pomi(cid:218)dzy omówionymi w tym rozdziale wzorcami. Na przyk(cid:239)ad Fowler w swojej ksi(cid:200)(cid:285)ce opisuje SKRYPT TRANSAKCYJNY, który oddziela interfejs u(cid:285)ytkownika od apli- kacji, jednak nie udost(cid:218)pnia modelu obiektowego. P(cid:239)ynie z tego nast(cid:218)- puj(cid:200)cy wniosek: Je(cid:285)eli aplikacja wydziela kod zwi(cid:200)zany z dziedzin(cid:200) w postaci spójnego projektu dziedziny lu(cid:283)no zwi(cid:200)zanego z pozosta(cid:239)(cid:200) cz(cid:218)(cid:258)ci(cid:200) systemu, wtedy taka architektura prawdopodobnie mog(cid:239)aby zosta(cid:202) zmodyfikowana do postaci projektu sterowanego dziedzin(cid:200). Ka(cid:285)dy z innych stylów programowania ma swoje zastosowanie, a Ty, drogi Czytelniku, musisz nauczy(cid:202) si(cid:218) akceptowa(cid:202) kompromis pomi(cid:218)dzy z(cid:239)o(cid:285)ono(cid:258)ci(cid:200) a elastyczno(cid:258)ci(cid:200). W niektórych sytuacjach brak wydzielenia projektu dziedziny mo(cid:285)e by(cid:202) naprawd(cid:218) tragiczny. Je(cid:285)eli masz z(cid:239)o(cid:285)on(cid:200) aplikacj(cid:218) i zdecydowa(cid:239)e(cid:258) si(cid:218) na PROJEKT STEROWANY MODELEM, wytrwaj w tym do ko(cid:241)ca, zatrudnij niezb(cid:218)dnych ekspertów i unikaj INTE- LIGENTNEGO INTERFEJSU U(cid:191)YTKOWNIKA. ANTYWZORZEC INTELIGENTNEGO INTERFEJSU U(cid:191)YTKOWNIKA 105 Poleć książkęKup książkę Inne rodzaje izolacji Niestety, poza u(cid:285)ytkownikiem oraz infrastruktur(cid:200) istnieje wiele innych czynników, które mog(cid:200) zepsu(cid:202) delikatny model dziedziny. B(cid:218)dziesz musia(cid:239) radzi(cid:202) sobie z innymi elementami dziedziny, które nie b(cid:218)d(cid:200) w pe(cid:239)ni zintegrowane z Twoim modelem. B(cid:218)dziesz musia(cid:239) tak(cid:285)e wspó(cid:239)pracowa(cid:202) z innymi zespo(cid:239)ami programistów, które b(cid:218)d(cid:200) wykorzystywa(cid:202) inne modele tej samej dziedziny. To wszystko b(cid:218)d(cid:200) czynniki wp(cid:239)ywaj(cid:200)ce na zaciem- nienie modelu oraz zmniejszenie jego przydatno(cid:258)ci. Tymi zagadnieniami zajmiemy si(cid:218) w rozdziale 14., „Utrzymywanie integralno(cid:258)ci modelu”, w którym wprowadzimy takie wzorce jak KONTEKST ZWI(cid:107)ZANY oraz WARSTWA OCHRONY PRZED USZKODZENIEM (ang. anticorruption layer). Bardzo z(cid:239)o(cid:285)ony model dziedziny mo(cid:285)e sam sta(cid:202) si(cid:218) bezu(cid:285)yteczny. W rozdziale 15., „Destylacja”, zajmiemy si(cid:218) omówieniem metod umo(cid:285)- liwiaj(cid:200)cych warstwie dziedziny oddzielenie poj(cid:218)(cid:202) zasadniczych od tych wspieraj(cid:200)cych. Tym wszystkim zajmiemy si(cid:218) jednak pó(cid:283)niej. W kolejnym rozdziale natomiast przyjrzymy si(cid:218) podstawom umo(cid:285)liwiaj(cid:200)cym wspólny rozwój efektywnego modelu dziedziny wraz z jego funkcjonaln(cid:200) implementacj(cid:200). Ostatecznie najwi(cid:218)kszym zyskiem z jej wydzielenia jest usuni(cid:218)cie wszyst- kich pozosta(cid:239)ych rzeczy z drogi, co u(cid:239)atwia rzeczywiste skoncentrowanie si(cid:218) na projektowani
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Domain-Driven Design. Zapanuj nad złożonym systemem informatycznym
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: