reklama - zainteresowany?

Nie b - Helion

Nie b
Autor: Tom Hombergs
Tytuł oryginału: Get Your Hands Dirty on Clean Architecture, 2nd Edition
Tłumaczenie: Robert G
ISBN: 978-83-289-1231-1
stron: 160, Format: 165x235, okładka: mi
Księgarnia: Helion

Cena książki: 49,90 zł

Książka będzie dostępna od października 2024

Tagi: Architektura oprogramowania | Inne - Programowanie

Wyobra

 

Zobacz także:

  • AWS dla architekt

Spis treści

Nie bój się ubrudzić rąk, tworząc czystą architekturę. Projektowanie aplikacji wysokiej jakości na przykładach w Javie. Wydanie II -- spis treści

Przedmowa

O autorze

O korektorach merytorycznych

Wprowadzenie

Rozdział 1. Łatwa obsługa techniczna

  • Co w ogóle oznacza łatwa obsługa techniczna?
  • Łatwa obsługa techniczna pozwala na większą funkcjonalność
  • Łatwa obsługa techniczna to zadowolenie programisty
  • Łatwość obsługi technicznej ułatwia podejmowanie decyzji
  • Zachowanie łatwości obsługi technicznej

Rozdział 2. Na czym polega problem z warstwami?

  • Warstwy wspierają projekt oparty na bazie danych
  • Warstwy są podatne na skróty
  • Warstwy utrudniają testowanie
  • Warstwy ukrywają przypadki użycia
  • Warstwy utrudniają pracę równoległą
  • W jaki sposób może to pomóc w tworzeniu oprogramowania łatwego w późniejszej obsłudze technicznej?

Rozdział 3. Odwracanie zależności

  • Reguła jednej odpowiedzialności
  • Opowieść o efektach ubocznych
  • Zasada odwrócenia zależności
  • Czysta architektura
  • Architektura heksagonalna
  • W jaki sposób może to pomóc w tworzeniu oprogramowania łatwego w późniejszej obsłudze technicznej?

Rozdział 4. Organizowanie kodu

  • Organizacja kodu za pomocą warstw
  • Organizacja kodu za pomocą funkcjonalności
  • Architekturalnie ekspresyjna struktura pakietu
  • Rola wstrzykiwania zależności
  • W jaki sposób może to pomóc w tworzeniu oprogramowania łatwego w późniejszej obsłudze technicznej?

Rozdział 5. Implementowanie przypadku użycia

  • Implementowanie modelu dziedziny
  • Krótki opis przypadku użycia
  • Weryfikowanie danych wejściowych
  • Potężne konstruktory
  • Różne modele danych wejściowych dla różnych przypadków użycia
  • Weryfikowanie reguł biznesowych
  • Rozbudowany kontra uproszczony model dziedziny
  • Różne modele danych wyjściowych dla różnych przypadków użycia
  • Przypadki użycia przeznaczone tylko do odczytu
  • W jaki sposób może to pomóc w tworzeniu oprogramowania łatwego w późniejszej obsłudze technicznej?

Rozdział 6. Implementowanie adaptera internetowego

  • Odwrócenie zależności
  • Zadania adaptera internetowego
  • Kontrolery wycinków adaptera internetowego
  • W jaki sposób może to pomóc w tworzeniu oprogramowania łatwego w późniejszej obsłudze technicznej?

Rozdział 7. Implementowanie adaptera trwałego magazynu danych

  • Odwrócenie zależności
  • Zadania adaptera trwałego magazynu danych
  • Dzielenie interfejsów portu
  • Dzielenie adapterów trwałego magazynu danych
  • Przykład oparty na JPA Spring Data
  • Transakcje bazy danych
  • W jaki sposób może to pomóc w tworzeniu oprogramowania łatwego w późniejszej obsłudze technicznej?

Rozdział 8. Testowanie elementów architektury

  • Piramida testów
  • Testowanie encji dziedziny za pomocą testów jednostkowych
  • Testowanie przypadku użycia za pomocą testu jednostkowego
  • Testowanie adaptera internetowego za pomocą testów integracyjnych
  • Testowanie adaptera trwałego magazynu danych za pomocą testów integracyjnych
  • Testowanie ścieżek głównych za pomocą testów systemowych
  • Jaka liczba testów będzie wystarczająca?
  • W jaki sposób może to pomóc w tworzeniu oprogramowania łatwego w późniejszej obsłudze technicznej?

Rozdział 9. Mapowanie między granicami

  • Strategia braku mapowania
  • Strategia mapowania dwukierunkowego
  • Strategia mapowania pełnego
  • Strategia mapowania jednokierunkowego
  • Kiedy należy używać poszczególnych rodzajów mapowania?
  • W jaki sposób może to pomóc w tworzeniu oprogramowania łatwego w późniejszej obsłudze technicznej?

Rozdział 10. Złożenie aplikacji w całość

  • Dlaczego złożenie wszystkiego w całość ma znaczenie?
  • Połączenie elementów za pomocą zwykłego kodu
  • Złożenie aplikacji poprzez skanowanie ścieżki classpath przeprowadzane przez Springa
  • Złożenie aplikacji poprzez konfigurację Javy w Springu
  • W jaki sposób może to pomóc w tworzeniu oprogramowania łatwego w późniejszej obsłudze technicznej?

Rozdział 11. Rozsądne używanie skrótów

  • Dlaczego skrót przypomina wybitą szybę?
  • Odpowiedzialność za dobry początek
  • Współdzielenie modeli między przypadkami użycia
  • Używanie encji dziedziny jako modeli danych wejściowych lub wyjściowych
  • Pomijanie portów wejściowych
  • Pomijanie usług
  • W jaki sposób może to pomóc w tworzeniu oprogramowania łatwego w późniejszej obsłudze technicznej?

Rozdział 12. Egzekwowanie granic architektury

  • Granice i zależności
  • Modyfikatory widoczności
  • Funkcja przystosowania wykonywana po przeprowadzeniu kompilacji
  • Artefakty kompilacji
  • W jaki sposób może to pomóc w tworzeniu oprogramowania łatwego w późniejszej obsłudze technicznej?

Rozdział 13. Zarządzanie wieloma ograniczonymi kontekstami

  • Jeden sześciokąt dla ograniczonego kontekstu?
  • Rozdzielone ograniczone konteksty
  • Poprawne połączenie ograniczonych kontekstów
  • W jaki sposób może to pomóc w tworzeniu oprogramowania łatwego w późniejszej obsłudze technicznej?

Rozdział 14. Podejście do architektury oprogramowania oparte na komponentach

  • Modułowość dzięki komponentom
  • Przykład: tworzenie komponentu typu "silnik sprawdzania"
  • Egzekwowanie granic komponentów
  • W jaki sposób może to pomóc w tworzeniu oprogramowania łatwego w późniejszej obsłudze technicznej?

Rozdział 15. Wybór stylu architekturalnego

  • Rozpocznij od prostego rozwiązania
  • Ewolucja dziedziny
  • Zaufaj swojemu doświadczeniu
  • To zależy

Code, Publish & WebDesing by CATALIST.com.pl



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