reklama - zainteresowany?

Domain-Driven Design. Zapanuj nad z - Helion

Domain-Driven Design. Zapanuj nad z
Autor: Eric Evans
Tytuł oryginału: Domain-Driven Design: Tackling Complexity in the Heart of Software
Tłumaczenie: Rafa
ISBN: 978-83-283-9184-0
stron: 584, Format: 168x237, okładka: mi
Data wydania: 2015-07-06
Księgarnia: Helion

Cena książki: 129,00 zł

Dodaj do koszyka Domain-Driven Design. Zapanuj nad z

Tagi: Inne - Programowanie | Techniki programowania

Zmie

Dodaj do koszyka Domain-Driven Design. Zapanuj nad z

 

Osoby które kupowały "Domain-Driven Design. Zapanuj nad z", wybierały także:

  • Zosta
  • Metoda dziel i zwyci
  • Matematyka. Kurs video. Teoria dla programisty i data science
  • Design Thinking. Kurs video. My
  • Konwolucyjne sieci neuronowe. Kurs video. Tensorflow i Keras w rozpoznawaniu obraz

Dodaj do koszyka Domain-Driven Design. Zapanuj nad z

Spis treści

Domain-Driven Design. Zapanuj nad złożonym systemem informatycznym -- 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ęć

Dodaj do koszyka Domain-Driven Design. Zapanuj nad z

Code, Publish & WebDesing by CATALIST.com.pl



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