Darmowy fragment publikacji:
Tytuł oryginału: Implementing Domain-Driven Design
Tłumaczenie: Radosław Meryk
Projekt okładki: Studio Gravite / Olsztyn
Obarek, Pokoński, Pazdrijowski, Zaprucki
ISBN: 978-83-283-2547-0
Authorized translation from the English language edition, entitled: IMPLEMENTING DOMAIN-DRIVEN
DESIGN; ISBN 0321834577; by Vaughn Vernon; published by Pearson Education, Inc, publishing as
Addison Wesley.
Copyright © 2013 Pearson Education, Inc.
All rights reserved. No part of this book may by reproduced or transmitted in any form or by any means,
electronic or mechanical, including photocopying, recording or by any information storage retrieval system,
without permission from Pearson Education, Inc.
Polish language edition published by HELION S.A. Copyright © 2016.
Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej
publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną,
fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje
naruszenie praw autorskich niniejszej publikacji.
Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich
właścicieli.
Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były
kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane
z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie
ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji
zawartych w książce.
Wydawnictwo 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)
Materiały graficzne na okładce zostały wykorzystane za zgodą Shutterstock Images LLC.
Pliki z przykładami omawianymi w książce można znaleźć pod adresem:
ftp://ftp.helion.pl/przyklady/dddaro.zip
Drogi Czytelniku!
Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres
http://helion.pl/user/opinie/dddaro
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:258)ci
S(cid:239)owo wst(cid:218)pne ............................................................................................... 15
Przedmowa .................................................................................................... 17
Podzi(cid:218)kowania ............................................................................................... 29
O autorze ...................................................................................................... 33
Przewodnik po tej ksi(cid:200)(cid:285)ce .............................................................................. 35
Rozdzia(cid:239) 1. Wprowadzenie w DDD .............................................................. 43
Czy mog(cid:218) zastosowa(cid:202) DDD? .......................................................................... 44
Dlaczego nale(cid:285)y stosowa(cid:202) DDD? ................................................................... 49
W jaki sposób stosowa(cid:202) DDD? ....................................................................... 64
Warto(cid:258)(cid:202) biznesowa u(cid:285)ywania technik DDD ................................................... 70
1. Organizacja zyskuje przydatny model swojej dziedziny .......................... 71
2. Powstaje udoskonalona i dok(cid:239)adna definicja biznesu ............................. 71
3. Eksperci dziedziny przyczyniaj(cid:200) si(cid:218) do tworzenia projektu
oprogramowania .................................................................................. 72
4. U(cid:285)ytkownicy zyskuj(cid:200) system wygodniejszy do u(cid:285)ywania ........................ 72
5. Wokó(cid:239) modeli tworzone s(cid:200) czytelne granice ........................................... 73
6. Architektura przedsi(cid:218)biorstwa jest lepiej zorganizowana ........................ 73
7. Stosowane jest zwinne, iteracyjne, ci(cid:200)g(cid:239)e modelowanie ......................... 73
8. Wykorzystywane s(cid:200) nowe narz(cid:218)dzia, zarówno na poziomie strategicznym,
jak i taktycznym ................................................................................... 74
Wyzwania zwi(cid:200)zane ze stosowaniem DDD ..................................................... 74
Fikcja z du(cid:285)(cid:200) dawk(cid:200) realizmu ......................................................................... 84
Podsumowanie .............................................................................................. 87
Rozdzia(cid:239) 2. Dziedziny, Poddziedziny i Konteksty Ograniczone .................... 89
Szeroka perspektywa ...................................................................................... 90
Poddziedziny i Konteksty Ograniczone w akcji .......................................... 90
Dziedzina G(cid:239)ówna w centrum uwagi ........................................................ 96
Dlaczego projektowanie strategiczne jest tak wa(cid:285)ne? ...................................... 99
(cid:165)wiat prawdziwych Dziedzin i Poddziedzin .................................................. 103
Nadawanie sensu Kontekstom Ograniczonym .............................................. 109
Nie tylko model ..................................................................................... 114
Rozmiar Kontekstów Ograniczonych ....................................................... 116
Zrównanie z komponentami technicznymi .............................................. 119
Przyk(cid:239)adowe Konteksty ................................................................................ 120
Kontekst Wspó(cid:239)praca .............................................................................. 121
Kontekst To(cid:285)samo(cid:258)(cid:202) i Dost(cid:218)p .................................................................. 128
Kontekst Zarz(cid:200)dzanie Projektem Agile ..................................................... 130
Podsumowanie ............................................................................................ 133
Poleć książkęKup książkę 10
S P I S T R E (cid:165) C I
Rozdzia(cid:239) 3. Mapy Kontekstu ...................................................................... 135
Dlaczego Mapy Kontekstu s(cid:200) takie wa(cid:285)ne? ...................................................136
Rysowanie Mapy Kontekstu ....................................................................138
Projekty i relacje organizacyjne ...............................................................140
Sporz(cid:200)dzenie mapy trzech Kontekstów ....................................................143
Podsumowanie .............................................................................................160
Rozdzia(cid:239) 4. Architektura ............................................................................ 163
Wywiad z cz(cid:239)owiekiem sukcesu — CIO firmy SaaSOvation ..........................165
Warstwy ......................................................................................................170
Zasada Odwracania Zale(cid:285)no(cid:258)ci ...............................................................174
Architektura Sze(cid:258)ciok(cid:200)tna albo Porty i Adaptery ...........................................176
Architektura ukierunkowana na us(cid:239)ugi .........................................................181
REST (Representational State Transfer) .......................................................185
REST jako styl architektoniczny ..............................................................185
Najwa(cid:285)niejsze cechy serwera HTTP typu RESTful ...................................187
Najwa(cid:285)niejsze cechy klienta HTTP typu RESTful ....................................188
REST i DDD ...........................................................................................189
Dlaczego REST? ......................................................................................190
CQRS (Command-Query Responsibility Segregation) ..................................191
Analiza obszarów wzorca CQRS ..............................................................193
Obs(cid:239)uga ostatecznie spójnego modelu zapyta(cid:241) .........................................200
Architektura Sterowana Zdarzeniami ...........................................................201
Potoki i Filtry .........................................................................................203
Procesy D(cid:239)ugotrwa(cid:239)e (Sagi) .....................................................................208
Magazynowanie Zdarze(cid:241) .........................................................................215
Przetwarzanie rozproszone z wykorzystaniem magazynów
Data Fabric i Grid .............................................................................219
Replikacja danych ...................................................................................220
Magazyny Fabric sterowane zdarzeniami a Zdarzenia Dziedziny ..............221
Ci(cid:200)g(cid:239)e Zapytania ....................................................................................222
Przetwarzanie rozproszone ......................................................................223
Podsumowanie .............................................................................................224
Rozdzia(cid:239) 5. Encje ........................................................................................ 227
Do czego u(cid:285)ywamy Encji? ............................................................................228
Unikatowa to(cid:285)samo(cid:258)(cid:202) ...................................................................................229
Identyfikator dostarczany przez u(cid:285)ytkownika ..........................................230
Identyfikator generowany przez aplikacj(cid:218) ................................................232
Identyfikator generowany przez mechanizm utrwalania ...........................236
Identyfikator przypisany przez inny Kontekst Ograniczony ......................239
Kiedy ma znaczenie czas generowania identyfikatora? .............................241
To(cid:285)samo(cid:258)(cid:202) zast(cid:218)pcza ...............................................................................243
Stabilno(cid:258)(cid:202) to(cid:285)samo(cid:258)ci .............................................................................246
Odkrywanie Encji i ich cech wrodzonych .....................................................249
Odkrywanie Encji i ich w(cid:239)a(cid:258)ciwo(cid:258)ci ........................................................250
Wyszukiwanie podstawowych zachowa(cid:241) .................................................254
Role i obowi(cid:200)zki .....................................................................................259
Konstrukcja ............................................................................................264
Poleć książkęKup książkę S P I S T R E (cid:165) C I
11
Walidacja ............................................................................................... 266
(cid:165)ledzenie zmian ...................................................................................... 275
Podsumowanie ............................................................................................ 276
Rozdzia(cid:239) 6. Obiekty Warto(cid:258)ci ..................................................................... 277
Cechy Warto(cid:258)ci ........................................................................................... 279
Mierzy, okre(cid:258)la ilo(cid:258)ciowo albo opisuje ..................................................... 279
Niezmienno(cid:258)(cid:202) ......................................................................................... 280
Poj(cid:218)ciowa Ca(cid:239)o(cid:258)(cid:202) ................................................................................... 281
Zast(cid:218)powalno(cid:258)(cid:202) ...................................................................................... 284
Równo(cid:258)(cid:202) Warto(cid:258)ci .................................................................................. 286
Zachowanie Pozbawione Skutków Ubocznych ......................................... 287
Minimalizm integracji .................................................................................. 292
Typy Standardowe wyra(cid:285)ane w formie Warto(cid:258)ci .......................................... 293
Testowanie Obiektów Warto(cid:258)ci ................................................................... 299
Implementacja ............................................................................................. 303
Utrwalanie Obiektów Warto(cid:258)ci .................................................................... 309
Unikaj niepotrzebnego Wyciekania Modelu Danych ................................ 310
ORM i pojedyncze Obiekty Warto(cid:258)ci ....................................................... 311
Mapowanie ORM i wiele Warto(cid:258)ci serializowanych
w pojedynczej kolumnie .................................................................... 314
Mechanizm ORM i wiele Warto(cid:258)ci dostarczanych
za pomoc(cid:200) encji bazy danych ............................................................ 315
ORM i wiele Warto(cid:258)ci dostarczanych za pomoc(cid:200) z(cid:239)(cid:200)czenia tabel .............. 320
Frameworki ORM i obiekty Enum reprezentuj(cid:200)ce Stan ............................ 321
Podsumowanie ............................................................................................ 324
Rozdzia(cid:239) 7. Us(cid:239)ugi ...................................................................................... 325
Czym jest Us(cid:239)uga Dziedziny (a przede wszystkim czym ona nie jest)? ............ 327
Upewnij si(cid:218), (cid:285)e potrzebujesz Us(cid:239)ugi .............................................................. 329
Modelowanie us(cid:239)ugi w dziedzinie ................................................................ 333
Czy wydzielony interfejs jest konieczny? ................................................. 335
Proces oblicze(cid:241) ....................................................................................... 338
Us(cid:239)ugi transformacji ............................................................................... 341
Pos(cid:239)ugiwanie si(cid:218) miniwarstw(cid:200) Us(cid:239)ug Dziedziny ....................................... 341
Testowanie Us(cid:239)ug ........................................................................................ 341
Podsumowanie ............................................................................................ 344
Rozdzia(cid:239) 8. Zdarzenia Dziedziny ................................................................ 347
Kiedy i dlaczego warto korzysta(cid:202) ze Zdarze(cid:241) Dziedziny? .............................. 347
Modelowanie Zdarze(cid:241) ................................................................................. 351
Zdarzenia z cechami Agregatu ................................................................. 356
To(cid:285)samo(cid:258)(cid:202) .............................................................................................. 357
Publikowanie Zdarze(cid:241) z Modelu Dziedziny ................................................. 359
Wydawca ............................................................................................... 359
Subskrybenci .......................................................................................... 363
Rozpowszechnianie wiadomo(cid:258)ci
w odleg(cid:239)ych Kontekstach Ograniczonych ............................................... 365
Spójno(cid:258)(cid:202) infrastruktury obs(cid:239)ugi komunikatów ......................................... 366
Autonomiczne Us(cid:239)ugi i Systemy .............................................................. 367
Tolerancje opó(cid:283)nie(cid:241) ............................................................................... 369
Poleć książkęKup książkę 12
S P I S T R E (cid:165) C I
Magazyn Zdarze(cid:241) ........................................................................................370
Style architektoniczne wysy(cid:239)ania zmagazynowanych Zdarze(cid:241) .......................375
Publikowanie powiadomie(cid:241) w postaci zasobów RESTful .........................375
Publikowanie powiadomie(cid:241) za pomoc(cid:200) warstwy middleware
obs(cid:239)ugi komunikatów ........................................................................380
Implementacja ..............................................................................................382
Publikowanie obiektów NotificationLog .................................................383
Publikowanie powiadomie(cid:241) bazuj(cid:200)cych na komunikatach .......................387
Podsumowanie .............................................................................................395
Rozdzia(cid:239) 9. Modu(cid:239)y .................................................................................... 397
Projektowanie z u(cid:285)yciem Modu(cid:239)ów ..............................................................398
Podstawowe konwencje nazewnictwa Modu(cid:239)ów ...........................................401
Konwencja nazewnictwa Modu(cid:239)ów w modelu ..............................................402
Modu(cid:239)y Kontekstu Zarz(cid:200)dzanie Projektem Agile ..........................................404
Modu(cid:239)y w innych warstwach .......................................................................407
Modu(cid:239) przed Kontekstem Ograniczonym .....................................................409
Podsumowanie .............................................................................................409
Rozdzia(cid:239) 10. Agregaty ................................................................................ 411
Zastosowanie Agregatów wewn(cid:200)trz Dziedziny G(cid:239)ównej Scrum .....................412
Pierwsza próba: Agregat w formie wielkiego klastra .................................413
Druga próba: wiele Agregatów ................................................................415
Regu(cid:239)a: rzeczywiste niezmienniki modelu w granicach spójno(cid:258)ci ..................418
Regu(cid:239)a: projektuj ma(cid:239)e Agregaty ..................................................................420
Nie ufaj wszystkim przypadkom u(cid:285)ycia ...................................................423
Regu(cid:239)a: odwo(cid:239)uj si(cid:218) do innych Agregatów
za pomoc(cid:200) identyfikatora to(cid:285)samo(cid:258)ci ......................................................424
Wspomaganie wspólnego dzia(cid:239)ania Agregatów
dzi(cid:218)ki referencjom ich identyfikatorów ..............................................426
Nawigowanie po modelu ........................................................................426
Skalowalno(cid:258)(cid:202) i dystrybucja .....................................................................429
Regu(cid:239)a: na zewn(cid:200)trz granicy u(cid:285)ywaj spójno(cid:258)ci ostatecznej ............................429
Zapytaj, czyje to zadanie ........................................................................432
Powody (cid:239)amania regu(cid:239) ..................................................................................433
Powód numer 1: wygoda interfejsu u(cid:285)ytkownika .....................................433
Powód numer 2: brak mechanizmów technicznych ..................................434
Powód numer 3: transakcje globalne .......................................................435
Powód numer 4: wydajno(cid:258)(cid:202) zapyta(cid:241) .......................................................435
Przestrzeganie regu(cid:239) .................................................................................436
Pozyskiwanie informacji przez odkrywanie ...................................................436
Ponowna analiza projektu .......................................................................436
Szacowanie kosztu Agregatu ....................................................................438
Powszechne scenariusze u(cid:285)ycia ................................................................439
Zu(cid:285)ycie pami(cid:218)ci ......................................................................................441
Analiza projektu alternatywnego .............................................................442
Implementacja spójno(cid:258)ci ostatecznej .......................................................443
Czy to jest zadanie cz(cid:239)onka zespo(cid:239)u? .......................................................445
Czas na decyzje .......................................................................................446
Poleć książkęKup książkę S P I S T R E (cid:165) C I
13
Implementacja ............................................................................................. 447
Utworzenie Encji G(cid:239)ównej z unikatowym identyfikatorem to(cid:285)samo(cid:258)ci ..... 447
Faworyzowanie Obiektów Warto(cid:258)ci ........................................................ 449
Wykorzystanie prawa Demeter oraz techniki „Powiedz, nie pytaj” ........... 449
Optymistyczna wspó(cid:239)bie(cid:285)no(cid:258)(cid:202) ................................................................ 452
Unikaj wstrzykiwania zale(cid:285)no(cid:258)ci ............................................................. 454
Podsumowanie ............................................................................................ 455
Rozdzia(cid:239) 11. Fabryki .................................................................................. 457
Fabryki w modelu dziedziny ........................................................................ 457
Metody Fabrykuj(cid:200)ce wewn(cid:200)trz Rdzenia Agregatu ........................................ 459
Tworzenie egzemplarzy obiektów CalendarEntry .................................... 460
Tworzenie egzemplarzy obiektu Discussion ............................................. 463
Fabryki na poziomie Us(cid:239)ug ........................................................................... 465
Podsumowanie ............................................................................................ 467
Rozdzia(cid:239) 12. Repozytoria ........................................................................... 469
Repozytoria typu kolekcja ............................................................................ 470
Implementacja z wykorzystaniem Hibernate ........................................... 476
Rozwa(cid:285)ania na temat implementacji bazuj(cid:200)cej na frameworku TopLink .... 484
Repozytoria typu trwa(cid:239)y magazyn ................................................................ 486
Implementacja z wykorzystaniem systemu Coherence ............................. 488
Implementacja na bazie MongoDB .......................................................... 494
Dodatkowe zachowanie ............................................................................... 499
Zarz(cid:200)dzanie transakcjami ............................................................................. 501
Ostrze(cid:285)enie ............................................................................................ 506
Hierarchie typów ......................................................................................... 506
Repozytoria a Obiekty Dost(cid:218)pu do Danych .................................................. 509
Testowanie Repozytoriów ........................................................................... 511
Testowanie z wykorzystaniem implementacji w pami(cid:218)ci .......................... 514
Podsumowanie ............................................................................................ 517
Rozdzia(cid:239) 13. Integrowanie Kontekstów Ograniczonych ............................. 519
Podstawy integracji ...................................................................................... 520
Systemy rozproszone s(cid:200) zasadniczo ró(cid:285)ne ................................................ 521
Wymienianie informacji poza granicami systemów .................................. 522
Integracja z wykorzystaniem zasobów RESTful ............................................ 529
Implementacja zasobu RESTful ............................................................... 530
Implementacja klienta REST z wykorzystaniem
Warstwy Zapobiegaj(cid:200)cej Uszkodzeniom ............................................. 533
Integracja z wykorzystaniem mechanizmu przekazywania komunikatów ...... 539
Zapewnienie dop(cid:239)ywu informacji
o w(cid:239)a(cid:258)cicielach produktu i cz(cid:239)onkach zespo(cid:239)u .................................... 540
Czy mo(cid:285)na przydzieli(cid:202) odpowiedzialno(cid:258)(cid:202)? ............................................... 546
D(cid:239)ugotrwa(cid:239)e procesy i unikanie odpowiedzialno(cid:258)ci .................................. 551
Maszyny stanu procesu i mechanizmy (cid:258)ledzenia limitu czasu ................... 563
Projektowanie bardziej zaawansowanych procesów ................................. 573
Gdy infrastruktura komunikatów lub system s(cid:200) niedost(cid:218)pne ................... 576
Podsumowanie ............................................................................................ 577
Poleć książkęKup książkę 14
S P I S T R E (cid:165) C I
Rozdzia(cid:239) 14. Aplikacja ............................................................................... 579
Interfejs u(cid:285)ytkownika ...................................................................................582
Renderowanie Obiektów Dziedziny .........................................................583
Renderowanie obiektów transferu danych
na podstawie egzemplarzy Agregatów ................................................584
U(cid:285)ycie Mediatora do publikowania wewn(cid:218)trznego stanu Agregatu ...........585
Renderowanie egzemplarzy Agregatów na podstawie obiektów DPO ........586
Reprezentacje stanu egzemplarzy Agregatu ...............................................587
Zapytania do Repozytorium zoptymalizowane dla przypadków u(cid:285)ycia .....588
Obs(cid:239)uga wielu odmiennych klientów .......................................................588
Adaptery renderowania i obs(cid:239)uga edycji u(cid:285)ytkownika ..............................589
Us(cid:239)ugi Aplikacji ............................................................................................592
Przyk(cid:239)ad Us(cid:239)ugi Aplikacji ........................................................................593
Oddzielone wyj(cid:258)cie us(cid:239)ugi .......................................................................599
Kompozycja wielu Kontekstów Ograniczonych ............................................603
Infrastruktura ...............................................................................................605
Kontenery komponentów .............................................................................606
Podsumowanie .............................................................................................609
Dodatek A. Agregaty i (cid:189)ród(cid:239)a Zdarze(cid:241): A+ES ........................................... 611
Wewn(cid:200)trz Us(cid:239)ugi Aplikacji ...........................................................................613
Handlery Polece(cid:241) .........................................................................................621
Sk(cid:239)adnia lambda ...........................................................................................625
Zarz(cid:200)dzanie wspó(cid:239)bie(cid:285)no(cid:258)ci(cid:200) ........................................................................626
Swoboda struktury przy zastosowaniu wzorca A+ES ....................................630
Wydajno(cid:258)(cid:202) ...................................................................................................630
Implementacja Magazynu Zdarze(cid:241) ...............................................................633
Utrwalanie z wykorzystaniem relacyjnej bazy danych ....................................637
Utrwalanie obiektów BLOB .........................................................................639
Agregaty ukierunkowane ..............................................................................641
Rzutowanie odczytów modelu ......................................................................642
Zastosowanie (cid:239)(cid:200)cznie z projektem bazuj(cid:200)cym na Agregatach .........................644
Wzbogacanie Zdarze(cid:241) ..................................................................................645
Narz(cid:218)dzia i wzorce pomocnicze ...................................................................647
Serializatory Zdarze(cid:241) ..............................................................................647
Niezmienno(cid:258)(cid:202) Zdarze(cid:241) ............................................................................649
Obiekty Warto(cid:258)ci ....................................................................................649
Generowanie kontraktu ...............................................................................652
Testy jednostkowe i specyfikacje ..................................................................653
Wsparcie dla wzorca A+ES w j(cid:218)zykach funkcyjnych .....................................655
Bibliografia ................................................................................................ 657
Skorowidz .................................................................................................. 661
Poleć książkęKup książkę Rozdzia(cid:225) 1.
Wprowadzenie w DDD
Projekt nie jest tylko tym, jak rzecz wygl(cid:200)da i jakie sprawia wra(cid:285)enie.
Projekt opisuje to, jak ona dzia(cid:239)a.
— Steve Jobs
Pracuj(cid:200)c nad oprogramowaniem, staramy si(cid:218), by by(cid:239)o ono wysokiej jako(cid:258)ci. Pewn(cid:200)
jako(cid:258)(cid:202) osi(cid:200)gamy poprzez zastosowanie testów, które pomagaj(cid:200) nam dostarcza(cid:202)
oprogramowanie z olbrzymi(cid:200) liczb(cid:200) b(cid:239)(cid:218)dów. Jednak(cid:285)e, nawet je(cid:258)li mogliby(cid:258)my
stworzy(cid:202) oprogramowanie zupe(cid:239)nie wolne od b(cid:239)(cid:218)dów, samo to niekoniecznie
oznacza, (cid:285)e zaprojektowany model oprogramowania jest wysokiej jako(cid:258)ci. Model
oprogramowania — sposób, w jaki oprogramowanie wyra(cid:285)a rozwi(cid:200)zanie poszu-
kiwanego problemu biznesowego — w dalszym ci(cid:200)gu mo(cid:285)e mie(cid:202) istotne wady.
Dostarczanie oprogramowania z ma(cid:239)(cid:200) liczb(cid:200) defektów jest oczywi(cid:258)cie dobre.
Mimo to mo(cid:285)emy si(cid:218)gn(cid:200)(cid:202) wy(cid:285)ej — po dobrze zaprojektowany model oprogra-
mowania, który jawnie odzwierciedla zamierzony cel biznesowy — a nasza praca
mo(cid:285)e nawet osi(cid:200)gn(cid:200)(cid:202) poziom doskona(cid:239)y.
Podej(cid:258)cie rozwoju oprogramowania okre(cid:258)lane jako Domain-Driven Design,
albo DDD, istnieje po to, by by(cid:239)o nam (cid:239)atwiej odnie(cid:258)(cid:202) sukces w tworzeniu wyso-
kiej jako(cid:258)ci projektów modelu oprogramowania. Je(cid:258)li metodyka DDD zostanie
prawid(cid:239)owo zaimplementowana, pomaga osi(cid:200)gn(cid:200)(cid:202) punkt, w którym nasz projekt
dok(cid:239)adnie prezentuje sposób, w jaki dzia(cid:239)a oprogramowanie. Celem tej ksi(cid:200)(cid:285)ki jest
udzielenie czytelnikom pomocy w prawid(cid:239)owej implementacji DDD.
Mo(cid:285)e DDD jest dla Ciebie zupe(cid:239)n(cid:200) nowo(cid:258)ci(cid:200). By(cid:202) mo(cid:285)e ju(cid:285) próbowa(cid:239)e(cid:258) pos(cid:239)u-
(cid:285)y(cid:202) si(cid:218) DDD i przychodzi(cid:239)o Ci to z trudem, a mo(cid:285)e wcze(cid:258)niej skutecznie zasto-
sowa(cid:239)e(cid:258) t(cid:218) metodyk(cid:218). Niezale(cid:285)nie od okoliczno(cid:258)ci bez w(cid:200)tpienia czytasz t(cid:218)
ksi(cid:200)(cid:285)k(cid:218) dlatego, (cid:285)e chcesz poprawi(cid:202) swoje umiej(cid:218)tno(cid:258)ci implementacji DDD —
i mo(cid:285)esz to osi(cid:200)gn(cid:200)(cid:202). „Mapa drogowa” rozdzia(cid:239)u pomo(cid:285)e Ci zaspokoi(cid:202) Twoje spe-
cyficzne potrzeby.
Mapa drogowa rozdzia(cid:239)u
• Podczas zmaga(cid:241) ze z(cid:239)o(cid:285)ono(cid:258)ci(cid:200) sprawdzisz, co Twoim projektom i zespo(cid:239)om
mo(cid:285)e zaoferowa(cid:202) DDD.
• Dowiesz si(cid:218), jak oceni(cid:202) projekt, by si(cid:218) przekona(cid:202), czy zas(cid:239)uguje on na zainwe-
stowanie w DDD.
Poleć książkęKup książkę 44
Rozdzia(cid:239) 1. W P R O W A D Z E N I E W DDD
• Rozwa(cid:285)ysz popularne alternatywy dla DDD i zastanowisz si(cid:218), dlaczego ich stoso-
wanie cz(cid:218)sto prowadzi do problemów.
• Nauczysz si(cid:218) podstaw DDD przy okazji zapoznawania si(cid:218) z pierwszymi krokami
w projekcie, które powiniene(cid:258) zrobi(cid:202).
• Dowiesz si(cid:218), jak przekaza(cid:202) zalety metodyki DDD kierownictwu, ekspertom dzie-
dziny i technicznym uczestnikom projektu.
• Staniesz wobec wyzwa(cid:241) stosowania DDD uzbrojony w wiedz(cid:218) o tym, jak mo(cid:285)esz
odnie(cid:258)(cid:202) sukces.
• Przyjrzysz si(cid:218) zespo(cid:239)owi, który uczy si(cid:218) sposobów implementacji DDD.
Czego powiniene(cid:258) oczekiwa(cid:202) od DDD? Nie jest to trudny, skomplikowany,
ceremonialny proces, który blokuje drog(cid:218) do post(cid:218)pów. Zamiast tego oczekuj sto-
sowania zwinnych technik projektowania, którym prawdopodobnie ju(cid:285) zaufa(cid:239)e(cid:258).
Poza tym przygotuj si(cid:218) na poznanie metod, które pomagaj(cid:200) zyska(cid:202) g(cid:239)(cid:218)boki wgl(cid:200)d
w Twoj(cid:200) dziedzin(cid:218) biznesow(cid:200). Jednocze(cid:258)nie daj(cid:200) perspektyw(cid:218) stworzenia modeli
oprogramowania, które s(cid:200) testowalne, elastyczne, uwa(cid:285)nie zorganizowane i sta-
rannie wykonane. S(cid:200) po prostu wysokiej jako(cid:258)ci.
DDD daje nam narz(cid:218)dzia zarówno do modelowania strategicznego, jak i tak-
tycznego. Narz(cid:218)dzia te s(cid:200) konieczne do projektowania wysokiej jako(cid:258)ci oprogra-
mowania, które spe(cid:239)nia podstawowe cele biznesowe.
Czy mog(cid:218) zastosowa(cid:202) DDD?
Mo(cid:285)esz zastosowa(cid:202) DDD, je(cid:285)eli masz:
(cid:120) pasj(cid:218) do tworzenia doskona(cid:239)ego oprogramowania codziennie oraz upór, by
osi(cid:200)gn(cid:200)(cid:202) ten cel;
(cid:120) gorliwo(cid:258)(cid:202) do nauki i osi(cid:200)gania post(cid:218)pów oraz hart ducha, aby przyzna(cid:202) si(cid:218) do
tego, (cid:285)e jest Ci to potrzebne;
(cid:120) zdolno(cid:258)ci do rozumienia wzorców oprogramowania oraz sposobów ich prawi-
d(cid:239)owego stosowania;
(cid:120) umiej(cid:218)tno(cid:258)ci i cierpliwo(cid:258)(cid:202) do odkrywania alternatywnych projektów z wyko-
rzystaniem sprawdzonych zwinnych metod wytwarzania oprogramowania;
(cid:120) odwag(cid:218) do stawiania wyzwa(cid:241) stanowi istniej(cid:200)cemu;
(cid:120) pragnienie zwracania uwagi na szczegó(cid:239)y i umiej(cid:218)tno(cid:258)(cid:202) ich dostrzegania oraz
upodobanie do eksperymentowania i odkrywania;
(cid:120) motywacj(cid:218) do szukania sposobów na lepsze i bardziej inteligentne kodowanie.
Poleć książkęKup książkę C Z Y M O G (cid:125) Z A S T O S O W A (cid:109) DDD?
45
Nie chc(cid:218) powiedzie(cid:202), (cid:285)e krzywa nauki nie istnieje. Mówi(cid:200)c otwarcie, krzywa
nauki bywa stroma. Pomimo to niniejsza ksi(cid:200)(cid:285)ka powsta(cid:239)a, aby pomóc sp(cid:239)aszczy(cid:202)
t(cid:218) krzyw(cid:200) tak bardzo, jak to mo(cid:285)liwe. Moim celem jest udzielenie czytelnikowi
i jego zespo(cid:239)owi pomocy w zastosowaniu metodyki DDD oraz zmaksymalizo-
waniu szans na odniesienie sukcesu.
DDD przede wszystkim nie dotyczy technologii. Podstawowe zasady DDD to:
dyskusja, s(cid:239)uchanie, zrozumienie, odkrywanie i warto(cid:258)(cid:202) biznesowa — wszystko
po to, aby scentralizowa(cid:202) wiedz(cid:218). Je(cid:285)eli masz zdolno(cid:258)(cid:202) rozumienia biznesu, w któ-
rym dzia(cid:239)a Twoje przedsi(cid:218)biorstwo, to zgodnie z planem minimum mo(cid:285)esz uczest-
niczy(cid:202) w procesie odkrywania modelu oprogramowania w celu stworzenia J(cid:218)zyka
Wszechobecnego. Oczywi(cid:258)cie b(cid:218)dziesz musia(cid:239) nauczy(cid:202) si(cid:218) o biznesie wi(cid:218)cej —
znacznie wi(cid:218)cej. Mimo to jeste(cid:258) na dobrej drodze do odniesienia sukcesu z DDD,
poniewa(cid:285) potrafisz rozumie(cid:202) poj(cid:218)cia swojego biznesu podczas rozwijania opro-
gramowania, a to tworzy w(cid:239)a(cid:258)ciw(cid:200) podstaw(cid:218) do zastosowania DDD w ca(cid:239)ym
procesie.
Czy posiadanie wieloletniego do(cid:258)wiadczenia w rozwoju oprogramowania jest
pomocne? By(cid:202) mo(cid:285)e. Niemniej jednak do(cid:258)wiadczenie w rozwijaniu oprogra-
mowania nie daje zdolno(cid:258)ci s(cid:239)uchania i uczenia si(cid:218) od ekspertów dziedziny —
ludzi, którzy wiedz(cid:200) najwi(cid:218)cej na temat obszarów biznesu o wysokim prioryte-
cie. Najwi(cid:218)cej mo(cid:285)na skorzysta(cid:202) z rozmów z osobami, które rzadko u(cid:285)ywaj(cid:200)
technicznego (cid:285)argonu (lub nigdy tego nie robi(cid:200)). Trzeba nauczy(cid:202) si(cid:218) uwa(cid:285)nie ich
s(cid:239)ucha(cid:202). Trzeba uszanowa(cid:202) ich punkt widzenia i zaufa(cid:202), (cid:285)e znaj(cid:200) temat znacznie
lepiej ni(cid:285) my sami.
Zaanga(cid:285)owanie ekspertów dziedziny przynosi du(cid:285)e korzy(cid:258)ci
Mo(cid:285)na du(cid:285)o skorzysta(cid:202) na rozmowach z osobami, które rzadko u(cid:285)ywaj(cid:200) technicznego
(cid:285)argonu (lub nigdy tego nie robi(cid:200)). Nie tylko Ty b(cid:218)dziesz uczy(cid:239) si(cid:218) od nich. Istnieje
du(cid:285)e prawdopodobie(cid:241)stwo, (cid:285)e oni tak(cid:285)e b(cid:218)d(cid:200) uczyli si(cid:218) od Ciebie.
Jedn(cid:200) z bardziej warto(cid:258)ciowych cech DDD jest to, (cid:285)e eksperci dziedziny rów-
nie(cid:285) musz(cid:200) pos(cid:239)ucha(cid:202) Ciebie. Jeste(cid:258)cie cz(cid:239)onkami tego samego zespo(cid:239)u. Chocia(cid:285)
mo(cid:285)e si(cid:218) to wydawa(cid:202) dziwne, eksperci dziedziny nie wiedz(cid:200) wszystkiego o swoim
biznesie i oni te(cid:285) powinni dowiedzie(cid:202) si(cid:218) o nim wi(cid:218)cej. Nie tylko Ty b(cid:218)dziesz
si(cid:218) uczy(cid:239) od nich. Istnieje du(cid:285)e prawdopodobie(cid:241)stwo, (cid:285)e oni tak(cid:285)e b(cid:218)d(cid:200) uczyli
si(cid:218) od Ciebie. Twoje pytania o to, co oni wiedz(cid:200), najprawdopodobniej spowo-
duj(cid:200) równie(cid:285) odkrycie tych obszarów, które nie s(cid:200) im znane tak samo dobrze.
B(cid:218)dziesz bezpo(cid:258)rednio zaanga(cid:285)owany w pomoc wszystkim osobom w zespole
w zdobywaniu g(cid:239)(cid:218)bszego zrozumienia biznesu — mo(cid:285)na nawet powiedzie(cid:202):
kszta(cid:239)towania biznesu.
To wspaniale, kiedy zespó(cid:239) uczy si(cid:218) i rozwija razem. Je(cid:285)eli dasz temu szans(cid:218),
metodyka DDD to umo(cid:285)liwi.
Poleć książkęKup książkę 46
Rozdzia(cid:239) 1. W P R O W A D Z E N I E W DDD
Nie mamy ekspertów dziedziny
Ekspert dziedziny to nie jest tytu(cid:239) zawodowy. Ekspertami dziedziny s(cid:200) ludzie, którzy
bardzo dobrze znaj(cid:200) obszar biznesu, w którym pracujesz. Cz(cid:218)sto maj(cid:200) oni obszern(cid:200)
wiedz(cid:218) w dziedzinie biznesowej. Zazwyczaj s(cid:200) to projektanci produktu albo osoby
z dzia(cid:239)u sprzeda(cid:285)y.
Nie zwracaj uwagi na nazwy stanowisk. Poszukiwani przez Ciebie ludzie o dzie-
dzinie, w której pracujesz, wiedz(cid:200) wi(cid:218)cej ni(cid:285) ktokolwiek inny i na pewno znacznie
wi(cid:218)cej ni(cid:285) Ty. Znajd(cid:283) ich. Pos(cid:239)uchaj. Naucz si(cid:218) czego(cid:258) od nich. Uwzgl(cid:218)dnij ich zda-
nie w projekcie kodu.
Dotychczas osi(cid:200)gn(cid:218)li(cid:258)my gotowo(cid:258)(cid:202) do spokojnego startu. Nie chcia(cid:239)bym jed-
nak powiedzie(cid:202), (cid:285)e umiej(cid:218)tno(cid:258)ci techniczne s(cid:200) niewa(cid:285)ne — (cid:285)e s(cid:200) czym(cid:258), bez czego
mo(cid:285)na si(cid:218) oby(cid:202). Trzeba si(cid:218) zapozna(cid:202) z zaawansowanymi poj(cid:218)ciami z zakresu
modelowania dziedziny w oprogramowaniu. Nie oznacza to jednak, (cid:285)e b(cid:218)dziemy
zmuszeni robi(cid:202) co(cid:258), co jest ponad nasze si(cid:239)y. Je(cid:258)li Twoje umiej(cid:218)tno(cid:258)ci mieszcz(cid:200)
si(cid:218) gdzie(cid:258) pomi(cid:218)dzy wiedz(cid:200) z ksi(cid:200)(cid:285)ki Head First Design Patterns [Freeman et al.]
a oryginaln(cid:200) zawarto(cid:258)ci(cid:200) pozycji Design Patterns [Gamma et al.] lub je(cid:258)li znasz
bardziej zaawansowane wzorce, to masz naprawd(cid:218) du(cid:285)e szanse na odniesienie
sukcesu z DDD. Mo(cid:285)esz na to liczy(cid:202). B(cid:218)d(cid:218) robi(cid:239) wszystko, co w mojej mocy,
aby sta(cid:239)o si(cid:218) to mo(cid:285)liwe. B(cid:218)d(cid:218) si(cid:218) stara(cid:239) „obni(cid:285)a(cid:202) poprzeczk(cid:218)”, niezale(cid:285)nie od tego,
jaki jest wyj(cid:258)ciowy poziom do(cid:258)wiadczenia czytelnika.
Co to jest Model Dziedziny?
To model oprogramowania bardzo okre(cid:258)lonej dziedziny biznesowej, w której pra-
cujesz. Cz(cid:218)sto jest on zaimplementowany jako model obiektowy, w którym obiekty
zawieraj(cid:200) zarówno dane, jak i zachowania w harmonii z dok(cid:239)adnym znaczeniem biz-
nesowym.
Stworzenie unikatowego, uwa(cid:285)nie zaprojektowanego Modelu Dziedziny, stano-
wi(cid:200)cego sedno podstawowej, strategicznej aplikacji albo podsystemu, ma zasadnicze zna-
czenie dla stosowania metodologii DDD. Dzi(cid:218)ki u(cid:285)yciu DDD Modele Dziedziny b(cid:218)d(cid:200)
mniej rozbudowane i bardzo skoncentrowane. Stosuj(cid:200)c DDD, nigdy nie próbujemy
zamodelowa(cid:202) ca(cid:239)ego przedsi(cid:218)biorstwa biznesowego w pojedynczym, olbrzymim Modelu
Dziedziny. To jest dobre!
Warto rozwa(cid:285)y(cid:202) wymienione poni(cid:285)ej perspektywy osób, które mog(cid:200) skorzy-
sta(cid:202) na stosowaniu DDD. Wiem, (cid:285)e czytelnik pasuje do jednej z tych grup.
(cid:120) Nowicjusz, m(cid:239)odszy deweloper: „Jestem m(cid:239)ody, ze (cid:258)wie(cid:285)ymi pomys(cid:239)ami. Mam
mnóstwo energii do kodowania i chc(cid:218) mie(cid:202) wp(cid:239)yw na projekt. Zdenerwo-
wa(cid:239) mnie jeden z projektów, w którym bra(cid:239)em udzia(cid:239). Nie oczekiwa(cid:239)em, (cid:285)e
ten mój pierwszy »koncert« poza kampusem studenckim b(cid:218)dzie oznacza(cid:239)
przerzucanie szufl(cid:200) danych w t(cid:218) i z powrotem, przy wykorzystaniu wielu pra-
wie identycznych, a jednak redundantnych obiektów. Dlaczego ta architektura
jest tak z(cid:239)o(cid:285)ona, skoro w oprogramowaniu dzieje si(cid:218) tak niewiele? Dlaczego
Poleć książkęKup książkę C Z Y M O G (cid:125) Z A S T O S O W A (cid:109) DDD?
47
tak jest? Kiedy staram si(cid:218) modyfikowa(cid:202) kod, ulega on cz(cid:218)stym awariom.
Czy kto(cid:258) w(cid:239)a(cid:258)ciwie rozumie, co on powinien robi(cid:202)? Mam teraz kilka z(cid:239)o(cid:285)onych
nowych funkcji do dodania. Regularnie tworz(cid:218) adaptery wokó(cid:239) istniej(cid:200)cych
klas, d(cid:200)(cid:285)(cid:200)c do tego, by unikn(cid:200)(cid:202) kiczu. (cid:191)adna przyjemno(cid:258)(cid:202). Jestem pewien,
(cid:285)e jest co(cid:258), co mog(cid:218) zrobi(cid:202) poza kodowaniem i debugowaniem dzie(cid:241) i noc
tylko po to, aby doko(cid:241)czy(cid:202) iteracje. Cokolwiek to jest, b(cid:218)d(cid:218) si(cid:218) stara(cid:239) to zna-
le(cid:283)(cid:202) i pozna(cid:202). Us(cid:239)ysza(cid:239)em rozmowy kilku osób na temat DDD. To brzmi jak
Gang Czterech, ale dostosowany do modelu dziedziny. Doskonale”.
Musz(cid:218) si(cid:218) z tym zapozna(cid:202).
(cid:120) (cid:165)rednio zaawansowany deweloper: „Kilka ostatnich miesi(cid:218)cy sp(cid:218)dzi(cid:239)em przy
nowym projekcie. Moj(cid:200) rol(cid:200) jest stworzenie ró(cid:285)nicy. Rozumiem, co si(cid:218) dzieje
w projekcie, ale brakuje mi g(cid:239)(cid:218)bokiej wiedzy, kiedy spotykam si(cid:218) ze star-
szymi deweloperami. Wydaje mi si(cid:218), (cid:285)e niektóre sprawy przebiegaj(cid:200) (cid:283)le, ale nie
jestem pewien, dlaczego tak jest. Mam zamiar pomóc zmieni(cid:202) sposób, w jaki
s(cid:200) realizowane funkcje. Wiem, (cid:285)e zastosowanie okre(cid:258)lonej technologii do roz-
wi(cid:200)zania problemu pozwala dotrze(cid:202) tylko do pewnego miejsca. Ogólnie rzecz
bior(cid:200)c, to nie jest wystarczaj(cid:200)co daleko. Potrzebuj(cid:218) zdrowej techniki rozwoju
oprogramowania, która pomo(cid:285)e mi sta(cid:202) si(cid:218) m(cid:200)drym i do(cid:258)wiadczonym twórc(cid:200)
oprogramowania. Jeden ze starszych architektów, nowa osoba w projekcie,
wspomnia(cid:239) o metodologii, która nazywa si(cid:218) DDD. Postanowi(cid:239)em si(cid:218) temu
przys(cid:239)ucha(cid:202)”.
W tym momencie mówisz ju(cid:285) jak do(cid:258)wiadczony programista. Kontynuuj
lektur(cid:218). Twoje nastawienie i „my(cid:258)lenie do przodu” b(cid:218)d(cid:200) nagrodzone.
(cid:120) Starszy deweloper, architekt: „U(cid:285)ywa(cid:239)em metodyki DDD w kilku projektach,
ale odk(cid:200)d obj(cid:200)(cid:239)em nowe stanowisko, jeszcze jej nie stosowa(cid:239)em. Lubi(cid:218) mo(cid:285)li-
wo(cid:258)ci wzorców taktycznych, lecz móg(cid:239)bym osi(cid:200)gn(cid:200)(cid:202) znacznie wi(cid:218)cej, wykorzy-
stuj(cid:200)c projektowanie strategiczne. Kiedy czyta(cid:239)em [Evans], najwi(cid:218)ksze wra(cid:285)enie
wywar(cid:239) na mnie J(cid:218)zyk Wszechobecny. To pot(cid:218)(cid:285)ne narz(cid:218)dzie. Dyskutowa(cid:239)em
z kilkoma kolegami z mojego zespo(cid:239)u i z kierownictwa, staraj(cid:200)c si(cid:218) wp(cid:239)yn(cid:200)(cid:202)
na ich pogl(cid:200)d na temat zastosowania DDD. Perspektywy u(cid:285)ycia tej metodyki
budz(cid:200) ogromne podekscytowanie jednego z nowych cz(cid:239)onków zespo(cid:239)u, a tak(cid:285)e
kilku (cid:258)rednio zaawansowanych i starszych programistów. Kierownictwo nie
podziela tego entuzjazmu. Do(cid:239)(cid:200)czy(cid:239)em do tej firmy niedawno i chocia(cid:285)
otrzyma(cid:239)em zadanie bycia liderem, to wydaje si(cid:218), (cid:285)e organizacja jest zainte-
resowana wprowadzaniem gwa(cid:239)townych usprawnie(cid:241) w mniejszym stopniu,
ni(cid:285) my(cid:258)la(cid:239)em. Wszystko jedno. I tak nie rezygnuj(cid:218). Je(cid:258)li uzyskam poparcie
innych deweloperów, to wiem, (cid:285)e b(cid:218)dziemy w stanie razem to osi(cid:200)gn(cid:200)(cid:202).
Korzy(cid:258)ci b(cid:218)d(cid:200) znacznie wi(cid:218)ksze ni(cid:285) oczekiwania. Zaprosimy ludzi zajmuj(cid:200)-
cych si(cid:218) wy(cid:239)(cid:200)cznie biznesem — ekspertów dziedziny — do bli(cid:285)szej wspó(cid:239)pracy
z zespo(cid:239)ami technicznymi i rzeczywi(cid:258)cie zainwestujemy w nasze rozwi(cid:200)zania,
zamiast ogranicza(cid:202) si(cid:218) wy(cid:239)(cid:200)cznie do ich produkowania — iteracja po iteracji”.
Poleć książkęKup książkę 48
Rozdzia(cid:239) 1. W P R O W A D Z E N I E W DDD
To jest dok(cid:239)adnie to, co powinien robi(cid:202) lider. W tej ksi(cid:200)(cid:285)ce zamieszczono
mnóstwo wskazówek, które pokazuj(cid:200), jak odnie(cid:258)(cid:202) sukces, stosuj(cid:200)c projekto-
wanie strategiczne.
(cid:120) Ekspert dziedziny: „Uczestnicz(cid:218) w specyfikowaniu rozwi(cid:200)za(cid:241) IT naszych
biznesowych wyzwa(cid:241) ju(cid:285) od d(cid:239)ugiego czasu. By(cid:202) mo(cid:285)e oczekuj(cid:218) zbyt wiele,
ale chcia(cid:239)bym, (cid:285)eby deweloperzy lepiej rozumieli, co my tutaj robimy. Zaw-
sze rozmawiaj(cid:200) z nami tak, jakby(cid:258)my byli nierozgarni(cid:218)ci. Nie rozumiej(cid:200), (cid:285)e
gdyby nie by(cid:239)o nas, to oni nie mieliby nic do roboty ze swoimi komputerami.
Deweloperzy zawsze w jaki(cid:258) dziwny sposób mówi(cid:200) o tym, co robi nasze opro-
gramowanie. Je(cid:285)eli mówimy o A, oni mówi(cid:200), (cid:285)e to tak naprawd(cid:218) nazywa si(cid:218) B.
Wydaje mi si(cid:218), (cid:285)e powinni(cid:258)my mie(cid:202) jaki(cid:258) rodzaj s(cid:239)ownika lub mapy drogowej
zawsze wtedy, gdy chcemy powiedzie(cid:202), czego potrzebujemy. Je(cid:258)li nie pozwa-
lamy deweloperom dzia(cid:239)a(cid:202) po swojemu, tzn. u(cid:285)ywa(cid:202) nazwy B w odniesieniu
do czego(cid:258), co my znamy jako A, to przestaj(cid:200) wspó(cid:239)pracowa(cid:202). Tracimy w ten
sposób mnóstwo czasu. Dlaczego oprogramowanie nie mo(cid:285)e dzia(cid:239)a(cid:202) dok(cid:239)ad-
nie tak, jak prawdziwi eksperci my(cid:258)l(cid:200) o biznesie?”.
Dobrze to uj(cid:200)(cid:239)e(cid:258). Jednym z najwi(cid:218)kszych problemów jest fa(cid:239)szywa potrzeba
t(cid:239)umaczenia przekazu pomi(cid:218)dzy lud(cid:283)mi biznesu a pracownikami technicznymi.
Ten rozdzia(cid:239) jest dla Ciebie. Jak si(cid:218) przekonasz, DDD stawia ekspertów dzie-
dziny i deweloperów na tym samym poziomie.
I jeszcze niespodzianka! Niektórzy deweloperzy ju(cid:285) sk(cid:239)aniaj(cid:200) si(cid:218) w Twoj(cid:200)
stron(cid:218). Pomó(cid:285) im w tym.
(cid:120) Mened(cid:285)er: „Dostarczamy oprogramowanie. Efekty nie zawsze s(cid:200) zgodne
z oczekiwaniami, a wprowadzanie zmian zwykle zajmuje wi(cid:218)cej czasu, ni(cid:285)
powinno. Deweloperzy stale mówi(cid:200) co(cid:258) o jakiej(cid:258) dziedzinie. Nie jestem pewien,
czy powinni(cid:258)my koncentrowa(cid:202) si(cid:218) na kolejnej technice albo metodologii,
s(cid:200)dz(cid:200)c, (cid:285)e b(cid:218)dzie ona rodzajem srebrnej kuli. S(cid:239)ysza(cid:239)em to wcze(cid:258)niej ju(cid:285) tysi(cid:200)c
razy. Próbujemy, entuzjazm zanika i znów wracamy do starego. Ci(cid:200)gle powta-
rzam, (cid:285)e powinni(cid:258)my trzyma(cid:202) kurs i przesta(cid:202) marzy(cid:202), ale zespó(cid:239) mnie naciska.
Pracuj(cid:200) ci(cid:218)(cid:285)ko, wi(cid:218)c powinienem ich wys(cid:239)ucha(cid:202). S(cid:200) inteligentnymi lud(cid:283)mi
i zas(cid:239)uguj(cid:200) na szans(cid:218) usprawnienia rzeczywisto(cid:258)ci. Je(cid:258)li jej im nie dam, zde-
nerwuj(cid:200) si(cid:218) i odejd(cid:200). Móg(cid:239)bym im da(cid:202) troch(cid:218) czasu na nauk(cid:218) i dostrojenie si(cid:218)
do nowej techniki, gdybym dosta(cid:239) zielone (cid:258)wiat(cid:239)o z wy(cid:285)szego szczebla zarz(cid:200)-
dzania. My(cid:258)l(cid:218), (cid:285)e móg(cid:239)bym zyska(cid:202) t(cid:218) aprobat(cid:218), gdybym móg(cid:239) przekona(cid:202)
mojego szefa do twierdze(cid:241) zespo(cid:239)u o kluczowej inwestycji w oprogramowa-
nie i centralizacji wiedzy biznesowej. Prawd(cid:200) jest, (cid:285)e moja praca by(cid:239)aby (cid:239)atwiej-
sza, gdybym móg(cid:239) co(cid:258) zrobi(cid:202), by wzbudzi(cid:202) zaufanie i ch(cid:218)(cid:202) wspó(cid:239)pracy pomi(cid:218)dzy
moimi zespo(cid:239)ami a ekspertami biznesowymi. W ka(cid:285)dym razie s(cid:239)ysz(cid:218), (cid:285)e w(cid:239)a-
(cid:258)nie to mog(cid:218) zrobi(cid:202)”.
Dobry mened(cid:285)er!
Poleć książkęKup książkę D L A C Z E G O N A L E (cid:191) Y S T O S O W A (cid:109) DDD?
49
Kimkolwiek jeste(cid:258), powiniene(cid:258) wzi(cid:200)(cid:202) pod uwag(cid:218) wa(cid:285)ne ostrze(cid:285)enie. Aby
odnie(cid:258)(cid:202) sukces z DDD, b(cid:218)dziesz musia(cid:239) si(cid:218) czego(cid:258) nauczy(cid:202). B(cid:218)dzie du(cid:285)o tego
czego(cid:258). Nie powinno to by(cid:202) jednak trudne. Jeste(cid:258) m(cid:200)dry i musisz uczy(cid:202) si(cid:218) przez
ca(cid:239)y czas. Pomimo wszystko ka(cid:285)dy z nas musi sprosta(cid:202) nast(cid:218)puj(cid:200)cemu wyzwaniu:
Osobi(cid:258)cie jestem zawsze gotowy, by si(cid:218) uczy(cid:202),
chocia(cid:285) nie zawsze lubi(cid:218), gdy kto(cid:258) mnie poucza.
— Sir Winston Churchill
Ta ksi(cid:200)(cid:285)ka ma w(cid:239)a(cid:258)nie taki cel: stara(cid:239)em si(cid:218), by nauczanie by(cid:239)o tak przyjemne,
jak to mo(cid:285)liwe, i by zapewnia(cid:239)o wiedz(cid:218) niezb(cid:218)dn(cid:200) do skutecznego zastosowania
technik DDD.
Czytelnik móg(cid:239)by jednak postawi(cid:202) pytanie: „Dlaczego nale(cid:285)y stosowa(cid:202) DDD?”.
To dobre pytanie.
Dlaczego nale(cid:285)y stosowa(cid:202) DDD?
W(cid:239)a(cid:258)ciwie ju(cid:285) wcze(cid:258)niej poda(cid:239)em kilka dobrych powodów, dla których zasto-
sowanie DDD ma tak bardzo praktyczny sens. Ryzykuj(cid:200)c z(cid:239)amanie zasady DRY
(ang. Don’t Repeat Yourself — dos(cid:239). nie powtarzaj si(cid:218)), ponownie przytocz(cid:218) je w tym
miejscu oraz dodam do nich kilka nowych powodów. Czy kto(cid:258) s(cid:239)ysza(cid:239) echo?
(cid:120) Umie(cid:258)(cid:202) ekspertów dziedziny i deweloperów na tym samym poziomie. Dzi(cid:218)ki
temu wytworzone oprogramowanie b(cid:218)dzie mia(cid:239)o sens tak(cid:285)e dla ludzi biznesu,
a nie tylko dla koderów. Nie oznacza to jedynie tolerowania przeciwnej grupy.
Oznacza stworzenie jednego spójnego i zwi(cid:218)z(cid:239)ego zespo(cid:239)u.
(cid:120) Fraza „ma sens dla ludzi biznesu” oznacza zainwestowanie w biznes poprzez
stworzenie oprogramowania, które maksymalnie b(cid:218)dzie przypomina(cid:202) sys-
tem, jaki stworzyliby biznesowi liderzy i eksperci dziedziny, gdyby sami byli
koderami.
(cid:120) Mo(cid:285)emy nauczy(cid:202) wszystkich cz(cid:239)onków zespo(cid:239)u wi(cid:218)cej o biznesie. (cid:191)aden
ekspert dziedziny, (cid:285)aden mened(cid:285)er szczebla C, nikt i nigdy nie wie wszystkiego
na temat biznesu. Poznawanie biznesu jest sta(cid:239)ym procesem odkrywania, który
z czasem staje si(cid:218) coraz bardziej wnikliwy. Dzi(cid:218)ki zastosowaniu DDD wszy-
scy si(cid:218) ucz(cid:200), poniewa(cid:285) ka(cid:285)dy co(cid:258) wnosi do odkrywczych dyskusji.
(cid:120) Centralizowanie wiedzy ma znaczenie kluczowe, gdy(cid:285) dzi(cid:218)ki temu mo(cid:285)na
zagwarantowa(cid:202), (cid:285)e rozumienie oprogramowanie nie b(cid:218)dzie zamkni(cid:218)t(cid:200) „wiedz(cid:200)
plemienn(cid:200)”, dost(cid:218)pn(cid:200) tylko dla kilku wybra(cid:241)ców — zazwyczaj deweloperów.
Poleć książkęKup książkę 50
Rozdzia(cid:239) 1. W P R O W A D Z E N I E W DDD
(cid:120) Nie ma niepotrzebnych t(cid:239)umacze(cid:241) przekazu pomi(cid:218)dzy ekspertami dziedziny,
deweloperami oprogramowania a oprogramowaniem. Nie oznacza to, (cid:285)e ist-
nieje kilka t(cid:239)umacze(cid:241). Oznacza to dok(cid:239)adnie zero t(cid:239)umacze(cid:241), poniewa(cid:285) zespó(cid:239)
rozwija wspólny j(cid:218)zyk, którym pos(cid:239)uguj(cid:200) si(cid:218) wszyscy jego cz(cid:239)onkowie.
(cid:120) Projekt jest kodem, a kod jest projektem. Projekt opisuje to, jak system dzia(cid:239)a.
Poznawanie najlepszych projektów kodu nast(cid:218)puje poprzez szybkie do(cid:258)wiad-
czalne modele tworzone z wykorzystaniem zwinnych procesów odkrywania.
(cid:120) Metodologia DDD dostarcza solidnych technik rozwoju oprogramowania,
które dotycz(cid:200) projektu zarówno na poziomie strategicznym, jak i taktycznym.
Projekt strategiczny pomaga nam zrozumie(cid:202), co stanowi najwa(cid:285)niejsz(cid:200) inwe-
stycj(cid:218) w oprogramowanie, jakie istniej(cid:200)ce zasoby oprogramowania mo(cid:285)na
wykorzysta(cid:202), aby zrealizowa(cid:202) j(cid:200) najszybciej i najbezpieczniej, oraz jakie osoby
powinny by(cid:202) w ni(cid:200) zaanga(cid:285)owane. Projekt taktyczny pomaga w utworzeniu
pojedynczego, eleganckiego modelu rozwi(cid:200)zania z wykorzystaniem przete-
stowanych bloków budulcowych oprogramowania.
Tak jak ka(cid:285)da dobra inwestycja, która ma przynie(cid:258)(cid:202) du(cid:285)e korzy(cid:258)ci, z zasto-
sowaniem metodologii DDD wi(cid:200)(cid:285)(cid:200) si(cid:218) pewne pocz(cid:200)tkowe koszty dotycz(cid:200)ce czasu
i wysi(cid:239)ków zespo(cid:239)u. Bior(cid:200)c pod uwag(cid:218) typowe wyzwania, jakie napotykamy
w ka(cid:285)dym przedsi(cid:218)wzi(cid:218)ciu zwi(cid:200)zanym z rozwojem oprogramowania, potrzeba
inwestowania w solidn(cid:200) metodologi(cid:218) wytwarzania oprogramowania wydaje si(cid:218)
szczególnie wa(cid:285)na.
Dostarczanie warto(cid:258)ci biznesowych mo(cid:285)e by(cid:202) ulotne
Rozwijanie oprogramowania, które dostarcza prawdziwej warto(cid:258)ci dla biznesu,
nie jest tym samym co rozwijanie zwyk(cid:239)ego biznesowego oprogramowania. Opro-
gramowanie dostarczaj(cid:200)ce prawdziwej warto(cid:258)ci biznesowej mo(cid:285)na porówna(cid:202) ze
strategicznymi inicjatywami w biznesie; przynosi ono rozwi(cid:200)zania, w których
mo(cid:285)na wyra(cid:283)nie zidentyfikowa(cid:202) konkurencyjn(cid:200) przewag(cid:218) — oprogramowanie,
którego sednem nie jest technologia, ale biznes.
Wiedza biznesowa nigdy nie jest scentralizowana. Zespo(cid:239)y programistów musz(cid:200)
zachowa(cid:202) równowag(cid:218) pomi(cid:218)dzy potrzebami i (cid:285)(cid:200)daniami wielu interesariuszy
oraz okre(cid:258)li(cid:202) ich priorytety, a ponadto zaanga(cid:285)owa(cid:202) wiele osób o ró(cid:285)norodnych
umiej(cid:218)tno(cid:258)ciach. Celem wszystkich tych przedsi(cid:218)wzi(cid:218)(cid:202) powinno by(cid:202) odkrywa-
nie funkcjonalnych i niefunkcjonalnych wymaga(cid:241) stawianych oprogramowaniu.
Jak po zebraniu wszystkich tych informacji mo(cid:285)na uzyska(cid:202) pewno(cid:258)(cid:202), (cid:285)e okre(cid:258)lone
wymaganie dostarcza prawdziwej warto(cid:258)ci biznesowej? Jak si(cid:218) dowiedzie(cid:202), jakich
warto(cid:258)ci biznesowych szukamy, jak je odkrywamy, nadajemy im priorytety i je
realizujemy?
Jednym z najbardziej dotkliwych problemów podczas realizowania zada(cid:241)
z zakresu rozwoju oprogramowania biznesowego jest luka pomi(cid:218)dzy ekspertami
Poleć książkęKup książkę D L A C Z E G O N A L E (cid:191) Y S T O S O W A (cid:109) DDD?
51
dziedziny a deweloperami oprogramowania. Ogólnie rzecz bior(cid:200)c, prawdziwi
eksperci dziedziny s(cid:200) skupieni na dostarczaniu warto(cid:258)ci biznesowych. Z drugiej
strony deweloperzy oprogramowania s(cid:200) zwykle skoncentrowani na technologii
oraz technicznych rozwi(cid:200)zaniach problemów biznesowych. Nie oznacza to, (cid:285)e
deweloperzy oprogramowania maj(cid:200) nieodpowiednie motywacje. Chodzi o to, (cid:285)e
to technika przyci(cid:200)ga ich uwag(cid:218). Nawet kiedy deweloperzy oprogramowania
zaczynaj(cid:200) wspó(cid:239)pracowa(cid:202) z ekspertami dziedziny, to wspó(cid:239)praca przebiega g(cid:239)ów-
nie powierzchownie, a w tworzonym oprogramowaniu zazwyczaj stosowane s(cid:200)
t(cid:239)umaczenia (odwzorowania) zwi(cid:200)zane z tym, w jaki sposób my(cid:258)li ekspert dzie-
dziny, i tym, jak to interpretuje deweloper oprogramowania. Powsta(cid:239)e w ten
sposób oprogramowanie zazwyczaj nie odzwierciedla rozpoznawalnej realizacji
mentalnego modelu ekspertów dziedziny albo robi to tylko cz(cid:218)(cid:258)ciowo. Z czasem
ten rozd(cid:283)wi(cid:218)k staje si(cid:218) kosztowny. T(cid:239)umaczenie wiedzy dziedzinowej na opro-
gramowanie gubi si(cid:218), gdy deweloperzy przechodz(cid:200) do innych projektów lub
odchodz(cid:200) z firmy.
Inny, cho(cid:202) powi(cid:200)zany z poprzednim, problem powstaje w sytuacji, kiedy
eksperci dziedziny nie zgadzaj(cid:200) si(cid:218) ze sob(cid:200). To si(cid:218) czasami zdarza, poniewa(cid:285)
ka(cid:285)dy ekspert ma mniej b(cid:200)d(cid:283) wi(cid:218)cej do(cid:258)wiadczenia w okre(cid:258)lonej modelowanej
dziedzinie, a niekiedy s(cid:200) to eksperci z powi(cid:200)zanych ze sob(cid:200), ale jednak innych
obszarów. Typowy dla wielu ekspertów dziedziny jest równie(cid:285) brak wiedzy spe-
cjalistycznej z zakresu okre(cid:258)lonej dziedziny. Czasem si(cid:218) zdarza, (cid:285)e tacy „eksperci”
s(cid:200) w wi(cid:218)kszym stopniu analitykami biznesowymi, cho(cid:202) oczekuje si(cid:218) od nich
rzeczowego wk(cid:239)adu w dyskusj(cid:218). Gdy taka sytuacja wymknie si(cid:218) spod kontroli,
w rezultacie zamiast ostrych powstaj(cid:200) rozmyte modele mentalne — co prowa-
dzi do koliduj(cid:200)cych ze sob(cid:200) modeli oprogramowania.
Jeszcze gorsza sytuacja wyst(cid:218)puje w przypadku, gdy zastosowanie technicznego
podej(cid:258)cia do rozwoju oprogramowania powoduje z(cid:239)(cid:200) zmian(cid:218) sposobu, w jaki
dzia(cid:239)a biznes. Chocia(cid:285) jest to troch(cid:218) inny scenariusz, to dobrze znane s(cid:200) sytu-
acje, gdy wdro(cid:285)enie oprogramowania ERP zmienia ogólny sposób dzia(cid:239)ania biz-
nesu w organizacji, tak by dopasowa(cid:202) si(cid:218) do sposobu funkcjonowania oprogra-
mowania ERP. Ca(cid:239)kowitego kosztu posiadania ERP nie mo(cid:285)na w pe(cid:239)ni obliczy(cid:202)
w kategoriach op(cid:239)at licencyjnych i konserwacyjnych. Reorganizacja i zak(cid:239)ócenie
dzia(cid:239)ania biznesu mog(cid:200) by(cid:202) o wiele bardziej kosztowne ni(cid:285) obydwa wymienione
czynniki namacalne. Podobna dynamika wyst(cid:218)puje w sytuacji, kiedy zespó(cid:239) roz-
woju oprogramowania interpretuje potrzeby biznesowe i przekszta(cid:239)ca je na fak-
tyczne dzia(cid:239)ania powstaj(cid:200)cego oprogramowania. Dla biznesu, klientów firmy
i jej partnerów mo(cid:285)e to powodowa(cid:202) powstanie zarówno kosztów, jak i zak(cid:239)óce(cid:241)
w pracy. Co wi(cid:218)cej, ta techniczna interpretacja jest i niepotrzebna, i mo(cid:285)liwa
do unikni(cid:218)cia. Wystarczy zastosowa(cid:202) sprawdzone techniki wytwarzania oprogra-
mowania. Rozwi(cid:200)zanie to jest kluczow(cid:200) inwestycj(cid:200).
Poleć książkęKup książkę 52
Rozdzia(cid:239) 1. W P R O W A D Z E N I E W DDD
W jaki sposób pomaga DDD?
DDD jest podej(cid:258)ciem do rozwijania oprogramowania, które skupia si(cid:218) na nast(cid:218)-
puj(cid:200)cych trzech najwa(cid:285)niejszych aspektach:
1. DDD (cid:239)(cid:200)czy ze sob(cid:200) ekspertów dziedziny i deweloperów oprogramowania,
stawiaj(cid:200)c przed nimi zadanie wytwarzania oprogramowania, które odzwier-
ciedla model mentalny ekspertów biznesowych. Nie oznacza to skoncentro-
wania wysi(cid:239)ków na modelowaniu „rzeczywistego (cid:258)wiata”. Zamiast niego DDD
dostarcza model, który jest najbardziej przydatny dla biznesu. Czasami przy-
datne i realistyczne modele przenikaj(cid:200) si(cid:218) wzajemnie, ale do momentu, w któ-
rym te modele si(cid:218) rozchodz(cid:200), DDD stosuje model najbardziej u(cid:285)yteczny.
Bior(cid:200)c pod uwag(cid:218) ten cel, eksperci dziedziny i deweloperzy oprogramowa-
nia wspólnie rozwijaj(cid:200) J(cid:218)zyk Wszechobecny tych obszarów biznesu, które s(cid:200)
modelowane. J(cid:218)zyk Wszechobecny jest rozwijany przy akceptacji ca(cid:239)ego
zespo(cid:239)u. Cz(cid:239)onkowie zespo(cid:239)u porozumiewaj(cid:200) si(cid:218) nim i jest on bezpo(cid:258)rednio
uwzgl(cid:218)dniony w modelu oprogramowania. Warto powtórzy(cid:202), (cid:285)e zespó(cid:239) sk(cid:239)ada
si(cid:218) zarówno z ekspertów dziedziny, jak i deweloperów oprogramowania.
Nigdy nie jest tak, (cid:285)e s(cid:200) „my” i „oni”. Zespó(cid:239) to zawsze my. To jest kluczowa
warto(cid:258)(cid:202) biznesowa, która pozwala przetrwa(cid:202) specjalistycznej wiedzy bizne-
sowej d(cid:239)u(cid:285)ej, ni(cid:285) trwaj(cid:200) stosunkowo krótkie pocz(cid:200)tkowe prace rozwojowe
zwi(cid:200)zane z kilkoma pierwszymi wersjami oprogramowania. Wiedza ta trwa
tak(cid:285)e d(cid:239)u(cid:285)ej, ni(cid:285) istniej(cid:200) zespo(cid:239)y, które to oprogramowanie wytworzy(cid:239)y. To
jest element, który udowadnia, (cid:285)e koszt rozwoju oprogramowania jest uza-
sadnion(cid:200) inwestycj(cid:200) biznesow(cid:200), a nie tylko zwyk(cid:239)ym kosztem.
Pode
Pobierz darmowy fragment (pdf)
