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

---

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

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

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

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

Dzięki tej książce:

zrozumiesz ideę Domain-Driven Design
nauczysz się tworzyć modele
zadbasz o integralność stworzonego modelu
uporządkujesz system za pomocą struktur dużej skali
rozpoznasz momenty przełomowe w trakcie modelowania oraz na nie zareagujesz
wykorzystasz DDD w Twoim (...) więcej projekcie

Sprawdź, jak projektować skomplikowane systemy informatyczne!
Spis treści:
Wyrazy uznania dla książki
Przedmowa
Wstęp

Trzy różne projekty
Wyzwanie złożoności
Proces projektowania a implementacja
Struktura książki
Kto powinien przeczytać tę książkę?
Zespół sterowany dziedziną

Podziękowania
I Zastosowanie modelu dziedziny

Przydatność modelu w projektowaniu sterowanym dziedziną
Istota programu

Rozdział 1. Przetwarzanie wiedzy

Elementy wydajnego modelowania
Przetwarzanie wiedzy
Ciągła nauka
Projekt bogaty w wiedzę
Modele dogłębne

Rozdział 2. Komunikacja i użycie języka

Język wszechobecny
Modelowanie na głos
Jeden zespół, jeden język
Dokumenty i diagramy

Spisane dokumenty projektowe
Wykonywalna podstawa

Modele objaśniające

Rozdział 3. Związanie modelu z implementacją

Projektowanie sterowane modelem
Paradygmaty modelowania i narzędzia wspierające

Projekt mechaniczny
Projekt sterowany modelem

Odkrywanie szkieletu dlaczego modele są ważne dla użytkowników
Modelowanie praktyczne

II Elementy składowe projektu sterowanego modelem
Rozdział 4. Wyizolowanie dziedziny

Architektura warstwowa

Powiązanie warstw
Szkielety architektury

To w warstwie dziedziny żyje model
Antywzorzec inteligentnego interfejsu użytkownika
Inne rodzaje izolacji

Rozdział 5. Wyrażenie modelu w programie

Asocjacje
ENCJE (zwane również obiektami referencyjnymi)

Modelowanie ENCJI
Projektowanie operacji na tożsamości

WARTOŚCI

Projektowanie OBIEKTÓW WARTOŚCI
Projektowanie asocjacji korzystających z WARTOŚCI

USŁUGI

USŁUGI a wyizolowana warstwa dziedziny
Ziarnistość
Dostęp do USŁUG

MODUŁY (zwane również PAKIETAMI)

MODUŁY zwinne (agile modules)
Pułapki tworzenia pakietów na podstawie wymogów infrastruktury

Paradygmaty modelowania

Dlaczego dominuje paradygmat obiektowy?
Nieobiekty w świecie obiektowym
Utrzymywanie PROJEKTU STEROWANEGO MODELEM w przypadku łączenia paradygmatów

Rozdział 6. Cykl życia obiektu dziedziny

AGREGATY
FABRYKI

Wybór FABRYK oraz ich miejsc
Kiedy potrzebujesz jedynie konstruktora
Projektowanie interfejsu
Gdzie mieści się logika niezmienników?
FABRYKI ENCJI a FABRYKI WARTOŚCI
Odtwarzanie zachowanych obiektów

REPOZYTORIA

Odpytywanie REPOZYTORIUM
Kod klienta, w przeciwieństwie do programistów, ignoruje implementację REPOZYTORIUM
Implementacja REPOZYTORIUM
Praca ze szkieletami architektury
Relacje z FABRYKAMI

Projektowanie obiektów dla relacyjnych baz danych

Rozdział 7. Użycie języka przykład rozszerzony

Prezentacja systemu logistycznego dla ładunku
Izolowanie dziedziny wprowadzenie aplikacji
Rozróżnianie ENCJI oraz WARTOŚCI

Role (rola) oraz inne atrybuty

Projektowanie asocjacji w dziedzinie logistyki morskiej
Granice AGREGATU
Wybór REPOZYTORIÓW
Przeglądanie scenariuszy

Przykładowa funkcjonalność aplikacji zmiana miejsca przeznaczenia ładunku
Przykładowa funkcjonalność aplikacji powtórzenie operacji

Tworzenie obiektów

FABRYKI oraz konstruktory klasy Cargo
Dodanie operacji obsługi

Przerwa na refaktoring projekt alternatywny AGREGATU Cargo
MODUŁY w modelu logistyki morskiej
Nowa funkcjonalność sprawdzanie przydziału

Łączenie dwóch systemów
Wzbogacanie modelu segmentacja biznesu
Poprawa wydajności

Ostateczna wersja

III Refaktoryzacja ku głębszemu zrozumieniu

Poziomy refaktoryzacji
Modele dogłębne
Model dogłębny/projekt elastyczny
Proces odkrywania

Rozdział 8. Moment przełomowy

Historia pewnego przełomu

Przyzwoity model, lecz wciąż...
Moment przełomowy
Model pogłębiony
Otrzeźwiająca decyzja
Zapłata

Możliwości
Koncentracja na podstawach
Epilog potok nowych spostrzeżeń

Rozdział 9. Odkrywanie pojęć niejawnych

Wyciąganie pojęć

Nasłuchiwanie języka
Analiza dziwnej implementacji
Rozmyślanie nad sprzecznościami
Czytanie książki
Wielokrotne powtarzanie prób

W jaki sposób zamodelować mniej oczywiste pojęcia

Bezpośrednie ograniczenia
Procesy jako obiekty dziedziny
SPECYFIKACJA
Zastosowanie SPECYFIKACJI w implementacji

Walidacja
Wybór (lub odszukiwanie)
Tworzenie na zamówienie (generowanie)

Rozdział 10. Projekt elastyczny

INTERFEJSY UJAWNIAJĄCE ZAMIAR
FUNKCJE BEZ EFEKTÓW UBOCZNYCH
ASERCJE

Teraz widzimy lepiej

ZARYSY KONCEPCYJNE

Nieprzewidziana zmiana

KLASY SAMODZIELNE
ZAMKNIĘCIE OPERACJI
Projektowanie deklaratywne

Języki właściwe dziedzinie

Deklaratywny styl projektowania

Rozszerzenie SPECYFIKACJI w stylu deklaratywnym

Łączenie SPECYFIKACJI przy użyciu operatorów logicznych

Subsumpcja

Kierunki ataku

Definiowanie poddziedzin
W miarę możliwości polegaj na ustalonym formalizmie

Wstępny projekt dystrybucji płatności
Oddzielanie poleceń oraz FUNKCJI BEZ EFEKTÓW UBOCZNYCH
Ujawnianie ukrytych pojęć
Obiekt SharePie staje się WARTOŚCIA kaskada spostrzeżeń
Elastyczność nowego projektu

Rozdział 11. Stosowanie wzorców analitycznych

Wzorce analityczne stanowią wiedzę do wykorzystania

Rozdział 12. Powiązanie wzorców projektowych z modelem

STRATEGIA (zwana również POLITYKĄ)
KOMPOZYT
Dlaczego nie wzorzec PYŁKU (FLYWEIGHT)?

Rozdział 13. Refaktoryzacja ku głębszemu zrozumieniu

Początek
Zespoły poszukiwawcze
Wcześniejsze odkrycia
Projekt dla programistów
Wyczucie czasu
Kryzys jako źródło możliwości

IV Projekt strategiczny
Rozdział 14. Utrzymywanie integralności modelu

KONTEKST ZWIĄZANY

Rozpoznawanie odprysków pojęciowych w KONTEKŚCIE ZWIĄZANYM

CIĄGŁA INTEGRACJA
MAPA KONTEKSTÓW

Testowanie na granicach KONTEKSTU
Organizacja oraz dokumentacja MAP KONTEKSTÓW

Relacje pomiędzy KONTEKSTAMI ZWIĄZANYMI
JĄDRO WSPÓŁDZIELONE
ZESPOŁY PROGRAMISTYCZNE KLIENTA DOSTAWCY
KONFORMISTA
WARSTWA ZAPOBIEGAJĄCA USZKODZENIU

Projektowanie interfejsu WARSTWY ZAPOBIEGAJĄCEJ USZKODZENIU
Implementacja WARSTWY ZAPOBIEGAJĄCEJ USZKODZENIU
Opowieść ku przestrodze

ODDZIELNE DROGI
USŁUGA OTWARTEGO GOSPODARZA
JĘZYK OPUBLIKOWANY
Unifikacja słonia
Wybór strategii kontekstu modelu

Decyzja zespołowa lub wyższa
Stawianie siebie w kontekście
Przekształcanie granic
Akceptacja tego, czego nie możemy zmienić wyznaczanie zewnętrznych systemów
Relacje z systemami zewnętrznymi
System w projektowaniu
Dostosowanie do specjalnych potrzeb przy użyciu odrębnych modeli
Wdrożenie
Kompromis
Kiedy projekt już trwa

Transformacje

Łączenie KONTEKSTÓW ODDZIELNE DROGI JĄDRO WSPÓŁDZIELONE
Łączenie KONTEKSTÓW JĄDRO WSPÓŁDZIELONE CIĄGŁA INTEGRACJA
Wygaszanie starego systemu
USŁUGA OTWARTEGO GOSPODARZA JĘZYK OPUBLIKOWANY

Rozdział 15. Destylacja

DZIEDZINA GŁÓWNA

Wybór RDZENIA dziedziny
Kto wykonuje prace?

Zwiększanie destylacji
PODDZIEDZINY OGÓLNE

Rozwiązanie 1. Gotowy, standaryzowany produkt
Rozwiązanie 2. Opublikowany projekt lub model
Rozwiązanie 3. Oddelegowanie implementacji
Rozwiązanie 4. Samodzielna implementacja
Ogólny nie oznacza możliwy do ponownego wykorzystania
Zarządzanie ryzykiem projektowym

OPIS WIZJI DZIEDZINY
RDZEŃ WYRÓŻNIONY

Dokument destylacji
RDZEŃ oznaczony
Dokument destylacji jako narzędzie procesowe

SPÓJNE MECHANIZMY

OGÓLNE PODDZIEDZINY a SPÓJNE MECHANIZMY
Kiedy MECHANIZM jest częścią DZIEDZINY GŁÓWNEJ

Destylacja do stylu deklaratywnego
RDZEŃ ODDZIELONY

Koszt utworzenia RDZENIA ODDZIELONEGO
Rozwijanie decyzji zespołowych

RDZEŃ ABSTRAKCYJNY
Głęboka destylacja modelu
Wybór celów refaktoryzacji

Rozdział 16. Struktury dużej skali

PORZĄDEK EWOLUCYJNY
METAFORA SYSTEMU

Dlaczego nie potrzebujemy metafory naiwnej

WARSTWY ODPOWIEDZIALNOŚCI

Odpowiedzialności operacyjne
Odpowiedzialności potencjału
Odpowiedzialności wsparcia decyzji
W jaki sposób struktura wpływa na bieżący projekt?
Wybór odpowiednich warstw

POZIOM WIEDZY
SZKIELET KOMPONENTÓW DOŁĄCZANYCH

Tworzenie elementu
Wybierz materiały
Tworzenie elementu

Jak ograniczająca powinna być struktura?
Refaktoryzacja ku lepiej dopasowanej strukturze

Minimalizm
Komunikacja oraz samodyscyplina
Restrukturyzacja przyczynia się do projektu elastycznego
Destylacja zmniejsza obciążenie

Rozdział 17. Łączenie strategii

Łączenie struktur dużej skali z KONTEKSTAMI ZWIĄZANYMI
Łączenie struktur dużej skali oraz destylacji
Najpierw oszacowanie
Kto określa strategię?

Powstawanie struktury w trakcie tworzenia aplikacji
Zespół architektoniczny skoncentrowany na kliencie

Sześć podstawowych kryteriów dotyczących podejmowania strategicznych decyzji projektowych

Decyzja musi dotrzeć do całego zespołu.
Proces podejmowania decyzji musi uwzględniać uwagi.
Plan musi umożliwiać rozwój.
Zespoły architektów nie mogą wyciągać wszystkich najlepszych i najbardziej błyskotliwych programistów.
Projekt strategiczny wymaga minimalizmu oraz pokory.
Obiekty są specjalizowane, programiści są uniwersalni.
To samo dotyczy szkieletów technicznych

Nie twórz szkieletów dla osób nierozgarniętych.

Wystrzegaj się planu głównego

Zakończenie

Epilog
Patrząc w przyszłość

Dodatek. Wykorzystanie szablonów z tej książki

NAZWA WZORCA

Słownik
Bibliografia
Prawa do zdjęć

O autorze: Eryk Evans jest twórcą Języka Dziedzinowego (ang. Domain Language), będącego grupą konsultingową, której celem jest pomoc firmom w tworzeniu oprogramowania powiązanego z ich biznesem. Od roku 1980 Eryk pracował w charakterze projektanta oraz programisty nad dużymi systemami obiektowymi w kilku złożonych dziedzinach biznesowych oraz technicznych. Dodatkowo wykształcił on zespoły programistów stosujących Programowanie Ekstremalne mniej