reklama - zainteresowany?

DDD dla architektów oprogramowania - Helion


Autor: Vaughn Vernon
Tytuł oryginału: Implementing Domain-Driven Design
Tłumaczenie: Radosław Meryk
ISBN: 978-83-283-2547-0
stron: 672, Format: 168x237, okładka: miękka
Data wydania: 2016-09-26
Księgarnia: Helion

Cena książki: 99,00 zł

Dodaj do koszyka

Tagi: Techniki programowania | Wzorce projektowe | Zarządzanie projektami IT

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:

  • wprowadzenie do DDD i główne zasady tego podejścia do projektowania
  • zastosowanie DDD w różnych architekturach, włącznie z architekturą sześciokątną, SOA, REST, CQRS, sterowaną zdarzeniami oraz Data Fabric (Grid)
  • zasady projektowania z wykorzystaniem encji i obiektów wartości
  • praktyczne stosowania takich technik DDD, jak zdarzenia dziedziny, moduły, agregaty
  • zasady implementacji integracji modelu z wykorzystaniem mapowania kontekstu oraz dziedziny głównej z kontekstami ograniczonymi
  • techniki projektowania repozytoriów dla rozwiązań ORM, NoSQL i wielu innych
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!

Dodaj do koszyka

Spis treści

DDD dla architektów oprogramowania -- spis treści

Słowo wstępne (15)

Przedmowa (17)

Podziękowania (29)

O autorze (33)

Przewodnik po tej książce (35)

Rozdział 1. Wprowadzenie w DDD (43)

  • Czy mogę zastosować DDD? (44)
  • Dlaczego należy stosować DDD? (49)
  • W jaki sposób stosować DDD? (64)
  • Wartość biznesowa używania technik DDD (70)
    • 1. Organizacja zyskuje przydatny model swojej dziedziny (71)
    • 2. Powstaje udoskonalona i dokładna definicja biznesu (71)
    • 3. Eksperci dziedziny przyczyniają się do tworzenia projektu oprogramowania (72)
    • 4. Użytkownicy zyskują system wygodniejszy do używania (72)
    • 5. Wokół modeli tworzone są czytelne granice (73)
    • 6. Architektura przedsiębiorstwa jest lepiej zorganizowana (73)
    • 7. Stosowane jest zwinne, iteracyjne, ciągłe modelowanie (73)
    • 8. Wykorzystywane są nowe narzędzia, zarówno na poziomie strategicznym, jak i taktycznym (74)
  • Wyzwania związane ze stosowaniem DDD (74)
  • Fikcja z dużą dawką realizmu (84)
  • Podsumowanie (87)

Rozdział 2. Dziedziny, Poddziedziny i Konteksty Ograniczone (89)

  • Szeroka perspektywa (90)
    • Poddziedziny i Konteksty Ograniczone w akcji (90)
    • Dziedzina Główna w centrum uwagi (96)
  • Dlaczego projektowanie strategiczne jest tak ważne? (99)
  • Ś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ładowe Konteksty (120)
    • Kontekst Współpraca (121)
    • Kontekst Tożsamość i Dostęp (128)
    • Kontekst Zarządzanie Projektem Agile (130)
  • Podsumowanie (133)

Rozdział 3. Mapy Kontekstu (135)

  • Dlaczego Mapy Kontekstu są takie ważne? (136)
    • Rysowanie Mapy Kontekstu (138)
    • Projekty i relacje organizacyjne (140)
    • Sporządzenie mapy trzech Kontekstów (143)
  • Podsumowanie (160)

Rozdział 4. Architektura (163)

  • Wywiad z człowiekiem sukcesu - CIO firmy SaaSOvation (165)
  • Warstwy (170)
    • Zasada Odwracania Zależności (174)
  • Architektura Sześciokątna albo Porty i Adaptery (176)
  • Architektura ukierunkowana na usługi (181)
  • REST (Representational State Transfer) (185)
    • REST jako styl architektoniczny (185)
    • Najważniejsze cechy serwera HTTP typu RESTful (187)
    • Najważ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ługa ostatecznie spójnego modelu zapytań (200)
  • Architektura Sterowana Zdarzeniami (201)
    • Potoki i Filtry (203)
    • Procesy Długotrwałe (Sagi) (208)
    • Magazynowanie Zdarzeń (215)
    • Przetwarzanie rozproszone z wykorzystaniem magazynów Data Fabric i Grid (219)
    • Replikacja danych (220)
    • Magazyny Fabric sterowane zdarzeniami a Zdarzenia Dziedziny (221)
    • Ciągłe Zapytania (222)
    • Przetwarzanie rozproszone (223)
  • Podsumowanie (224)

Rozdział 5. Encje (227)

  • Do czego używamy Encji? (228)
  • Unikatowa tożsamość (229)
    • Identyfikator dostarczany przez użytkownika (230)
    • Identyfikator generowany przez aplikację (232)
    • Identyfikator generowany przez mechanizm utrwalania (236)
    • Identyfikator przypisany przez inny Kontekst Ograniczony (239)
    • Kiedy ma znaczenie czas generowania identyfikatora? (241)
    • Tożsamość zastępcza (243)
    • Stabilność tożsamości (246)
  • Odkrywanie Encji i ich cech wrodzonych (249)
    • Odkrywanie Encji i ich właściwości (250)
    • Wyszukiwanie podstawowych zachowań (254)
    • Role i obowiązki (259)
    • Konstrukcja (264)
    • Walidacja (266)
    • Śledzenie zmian (275)
  • Podsumowanie (276)

Rozdział 6. Obiekty Wartości (277)

  • Cechy Wartości (279)
    • Mierzy, określa ilościowo albo opisuje (279)
    • Niezmienność (280)
    • Pojęciowa Całość (281)
    • Zastępowalność (284)
    • Równość Wartości (286)
    • Zachowanie Pozbawione Skutków Ubocznych (287)
  • Minimalizm integracji (292)
  • Typy Standardowe wyrażane w formie Wartości (293)
  • Testowanie Obiektów Wartości (299)
  • Implementacja (303)
  • Utrwalanie Obiektów Wartości (309)
    • Unikaj niepotrzebnego Wyciekania Modelu Danych (310)
    • ORM i pojedyncze Obiekty Wartości (311)
    • Mapowanie ORM i wiele Wartości serializowanych w pojedynczej kolumnie (314)
    • Mechanizm ORM i wiele Wartości dostarczanych za pomocą encji bazy danych (315)
    • ORM i wiele Wartości dostarczanych za pomocą złączenia tabel (320)
    • Frameworki ORM i obiekty Enum reprezentujące Stan (321)
  • Podsumowanie (324)

Rozdział 7. Usługi (325)

  • Czym jest Usługa Dziedziny (a przede wszystkim czym ona nie jest)? (327)
  • Upewnij się, że potrzebujesz Usługi (329)
  • Modelowanie usługi w dziedzinie (333)
    • Czy wydzielony interfejs jest konieczny? (335)
    • Proces obliczeń (338)
    • Usługi transformacji (341)
    • Posługiwanie się miniwarstwą Usług Dziedziny (341)
  • Testowanie Usług (341)
  • Podsumowanie (344)

Rozdział 8. Zdarzenia Dziedziny (347)

  • Kiedy i dlaczego warto korzystać ze Zdarzeń Dziedziny? (347)
  • Modelowanie Zdarzeń (351)
    • Zdarzenia z cechami Agregatu (356)
    • Tożsamość (357)
  • Publikowanie Zdarzeń z Modelu Dziedziny (359)
    • Wydawca (359)
    • Subskrybenci (363)
  • Rozpowszechnianie wiadomości w odległych Kontekstach Ograniczonych (365)
    • Spójność infrastruktury obsługi komunikatów (366)
    • Autonomiczne Usługi i Systemy (367)
    • Tolerancje opóźnień (369)
  • Magazyn Zdarzeń (370)
  • Style architektoniczne wysyłania zmagazynowanych Zdarzeń (375)
    • Publikowanie powiadomień w postaci zasobów RESTful (375)
    • Publikowanie powiadomień za pomocą warstwy middleware obsługi komunikatów (380)
  • Implementacja (382)
    • Publikowanie obiektów NotificationLog (383)
    • Publikowanie powiadomień bazujących na komunikatach (387)
  • Podsumowanie (395)

Rozdział 9. Moduły (397)

  • Projektowanie z użyciem Modułów (398)
  • Podstawowe konwencje nazewnictwa Modułów (401)
  • Konwencja nazewnictwa Modułów w modelu (402)
  • Moduły Kontekstu Zarządzanie Projektem Agile (404)
  • Moduły w innych warstwach (407)
  • Moduł przed Kontekstem Ograniczonym (409)
  • Podsumowanie (409)

Rozdział 10. Agregaty (411)

  • Zastosowanie Agregatów wewnątrz Dziedziny Głównej Scrum (412)
    • Pierwsza próba: Agregat w formie wielkiego klastra (413)
    • Druga próba: wiele Agregatów (415)
  • Reguła: rzeczywiste niezmienniki modelu w granicach spójności (418)
  • Reguła: projektuj małe Agregaty (420)
    • Nie ufaj wszystkim przypadkom użycia (423)
  • Reguła: odwołuj się do innych Agregatów za pomocą identyfikatora tożsamości (424)
    • Wspomaganie wspólnego działania Agregatów dzięki referencjom ich identyfikatorów (426)
    • Nawigowanie po modelu (426)
    • Skalowalność i dystrybucja (429)
  • Reguła: na zewnątrz granicy używaj spójności ostatecznej (429)
    • Zapytaj, czyje to zadanie (432)
  • Powody łamania reguł (433)
    • Powód numer 1: wygoda interfejsu użytkownika (433)
    • Powód numer 2: brak mechanizmów technicznych (434)
    • Powód numer 3: transakcje globalne (435)
    • Powód numer 4: wydajność zapytań (435)
    • Przestrzeganie reguł (436)
  • Pozyskiwanie informacji przez odkrywanie (436)
    • Ponowna analiza projektu (436)
    • Szacowanie kosztu Agregatu (438)
    • Powszechne scenariusze użycia (439)
    • Zużycie pamięci (441)
    • Analiza projektu alternatywnego (442)
    • Implementacja spójności ostatecznej (443)
    • Czy to jest zadanie członka zespołu? (445)
    • Czas na decyzje (446)
  • Implementacja (447)
    • Utworzenie Encji Głównej z unikatowym identyfikatorem tożsamości (447)
    • Faworyzowanie Obiektów Wartości (449)
    • Wykorzystanie prawa Demeter oraz techniki "Powiedz, nie pytaj" (449)
    • Optymistyczna współbieżność (452)
    • Unikaj wstrzykiwania zależności (454)
  • Podsumowanie (455)

Rozdział 11. Fabryki (457)

  • Fabryki w modelu dziedziny (457)
  • Metody Fabrykujące wewnątrz Rdzenia Agregatu (459)
    • Tworzenie egzemplarzy obiektów CalendarEntry (460)
    • Tworzenie egzemplarzy obiektu Discussion (463)
  • Fabryki na poziomie Usług (465)
  • Podsumowanie (467)

Rozdział 12. Repozytoria (469)

  • Repozytoria typu kolekcja (470)
    • Implementacja z wykorzystaniem Hibernate (476)
    • Rozważania na temat implementacji bazującej na frameworku TopLink (484)
  • Repozytoria typu trwały magazyn (486)
    • Implementacja z wykorzystaniem systemu Coherence (488)
    • Implementacja na bazie MongoDB (494)
  • Dodatkowe zachowanie (499)
  • Zarządzanie transakcjami (501)
    • Ostrzeżenie (506)
  • Hierarchie typów (506)
  • Repozytoria a Obiekty Dostępu do Danych (509)
  • Testowanie Repozytoriów (511)
    • Testowanie z wykorzystaniem implementacji w pamięci (514)
  • Podsumowanie (517)

Rozdział 13. Integrowanie Kontekstów Ograniczonych (519)

  • Podstawy integracji (520)
    • Systemy rozproszone są zasadniczo róż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ącej Uszkodzeniom (533)
  • Integracja z wykorzystaniem mechanizmu przekazywania komunikatów (539)
    • Zapewnienie dopływu informacji o właścicielach produktu i członkach zespołu (540)
    • Czy można przydzielić odpowiedzialność? (546)
    • Długotrwałe procesy i unikanie odpowiedzialności (551)
    • Maszyny stanu procesu i mechanizmy śledzenia limitu czasu (563)
    • Projektowanie bardziej zaawansowanych procesów (573)
    • Gdy infrastruktura komunikatów lub system są niedostępne (576)
  • Podsumowanie (577)

Rozdział 14. Aplikacja (579)

  • Interfejs użytkownika (582)
    • Renderowanie Obiektów Dziedziny (583)
    • Renderowanie obiektów transferu danych na podstawie egzemplarzy Agregatów (584)
    • Użycie Mediatora do publikowania wewnę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życia (588)
    • Obsługa wielu odmiennych klientów (588)
    • Adaptery renderowania i obsługa edycji użytkownika (589)
  • Usługi Aplikacji (592)
    • Przykład Usługi Aplikacji (593)
    • Oddzielone wyjście usługi (599)
  • Kompozycja wielu Kontekstów Ograniczonych (603)
  • Infrastruktura (605)
  • Kontenery komponentów (606)
  • Podsumowanie (609)

Dodatek A. Agregaty i Źródła Zdarzeń: A+ES (611)

  • Wewnątrz Usługi Aplikacji (613)
  • Handlery Poleceń (621)
  • Składnia lambda (625)
  • Zarządzanie współbieżnością (626)
  • Swoboda struktury przy zastosowaniu wzorca A+ES (630)
  • Wydajność (630)
  • Implementacja Magazynu Zdarzeń (633)
  • Utrwalanie z wykorzystaniem relacyjnej bazy danych (637)
  • Utrwalanie obiektów BLOB (639)
  • Agregaty ukierunkowane (641)
  • Rzutowanie odczytów modelu (642)
  • Zastosowanie łącznie z projektem bazującym na Agregatach (644)
  • Wzbogacanie Zdarzeń (645)
  • Narzędzia i wzorce pomocnicze (647)
    • Serializatory Zdarzeń (647)
    • Niezmienność Zdarzeń (649)
    • Obiekty Wartości (649)
  • Generowanie kontraktu (652)
  • Testy jednostkowe i specyfikacje (653)
  • Wsparcie dla wzorca A+ES w językach funkcyjnych (655)

Bibliografia (657)

Skorowidz (661)

Dodaj do koszyka

Code, Publish & WebDesing by CATALIST.com.pl



(c) 2005-2019 CATALIST agencja interaktywna, znaki firmowe należą do wydawnictwa Helion S.A.