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

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 projekcie

Sprawdź, jak projektować skomplikowane systemy informatyczne!

• 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ęć