Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00310 009668 7506814 na godz. na dobę w sumie
DDD dla architektów oprogramowania - ebook/pdf
DDD dla architektów oprogramowania - ebook/pdf
Autor: Liczba stron: 672
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-283-2548-7 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> biznes it >> zarządzanie projektami it
Porównaj ceny (książka, ebook (-50%), audiobook).
Sprawne budowanie dużych systemów oprogramowania jest nie lada wyzwaniem, zwłaszcza gdy trzeba spełnić specyficzne wymagania biznesowe. Programowanie dziedzinowe, zwane w skrócie DDD, jest nowatorskim podejściem do projektowania architektury oprogramowania, pozwalającym na szybkie uzyskiwanie pożądanych efektów. Wielu architektów stosuje DDD wyłącznie jako techniczny zbiór narzędzi i nie wykracza poza wykorzystywanie wzorców taktycznych. Tymczasem dopiero pełne wykorzystanie strategicznych wzorców projektowych DDD pozwoli na prawdziwie skuteczne projektowanie skomplikowanych systemów oprogramowania.

Niniejsza książka jest przeznaczona dla architektów aplikacji skali korporacyjnej. Zawarto tu wyczerpujący opis zbioru narzędzi DDD i ich stosowania do projektowania różnych systemów, a także w przystępny sposób pokazano aspekty praktycznego wykorzystania nowych technik, takich jak wzorce CQRS czy magazynowanie zdarzeń. Są one stosowane z upodobaniem przez wielu praktyków DDD. Zaprezentowano tu wiele przykładów i cennych wniosków. Jednym słowem, jest to kompletny podręcznik, z którego skorzystają wszyscy deweloperzy oprogramowania, niezależnie od posiadanego doświadczenia.

W książce przedstawiono następujące zagadnienia: Vernon Vaughn — projektant odpowiedzialny za rozwój architektury oprogramowania. Uznany lider nowatorskiego podejścia do upraszczania projektu i implementacji oprogramowania. Zasady programowania dziedzinowego stosuje w praktyce od lat dziewięćdziesiątych, tworząc modele oprogramowania dla takich branż, jak zarządzanie przestrzenią powietrzną, ochrona środowiska, ubezpieczenia, ochrona zdrowia czy telekomunikacja. Jest uznanym autorytetem w dziedzinie DDD — jego wykłady cieszą się wielką popularnością w wielu krajach.

Z DDD zaimplementujesz wszystko, co zechcesz!

Znajdź podobne książki

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)

Gdzie kupić całą publikację:

DDD dla architektów oprogramowania
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ą: