Domain-Driven Design. Zapanuj nad złożonym systemem informatycznym - ebook
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!
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
- Architektura warstwowa
- 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ń
- Historia pewnego przełomu
- 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)
- Wyciąganie pojęć
- 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
- Rozszerzenie SPECYFIKACJI w stylu deklaratywnym
- 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
- KONTEKST ZWIĄZANY
- 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
- DZIEDZINA GŁÓWNA
- 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ęć
Kategoria: | Programowanie |
Zabezpieczenie: |
Watermark
|
ISBN: | 978-83-283-9185-7 |
Rozmiar pliku: | 10 MB |