Proces Typ
Wyrażenie graficzne
Myślenie Typ
Wyrażenie strukturalne
Notatki Typ
Efektywne wyrażanie
Mapa drzewa
Schemat nawiasów
Tryb domyślny
W rozwoju oprogramowania odwieczne wyzwanie: wraz ze wzrostem złożoności logiki biznesowej, kod staje się coraz trudniejszy w utrzymaniu. Wczesne aplikacje CRUD oparte na architekturze MVC działają dobrze, ale wraz ze wzrostem potrzeb biznesowych, zespoły programistyczne szybko stają przed dylematem: „Gdzie umieścić logikę biznesową?”.
Aby rozwiązać ten problem, opracowano projektowanie zorientowane na domenę (DDD). Zaproponowane przez guru oprogramowania Erica Evansa w 2003 roku, ma ono na celu budowanie modeli oprogramowania ściśle dopasowanych do potrzeb biznesowych, wykorzystując wiedzę o danej dziedzinie biznesu jako główną siłę napędową projektowania systemów. DDD nie jest konkretnym stylem architektonicznym, lecz kompletną i systematyczną metodologią projektowania, która upraszcza złożone dziedziny biznesowe poprzez wytyczenie granic, pomagając nam projektować jasne granice domen i aplikacji.
W tym artykule systematycznie wyjaśnimy podstawowe koncepcje, projektowanie strategiczne i taktyczne oraz architekturę warstwową DDD . Niezależnie od tego, czy jesteś programistą, który dopiero zaczyna przygodę z DDD, czy menedżerem produktu lub architektem, który chce udoskonalić swoje umiejętności projektowania architektury, możesz czerpać z niego inspirację.
W tradycyjnych modelach programistycznych logika biznesowa jest często powiązana z operacjami baz danych i funkcjami frameworka, co skutkuje słabą czytelnością kodu i wysokimi kosztami utrzymania. Główną ideą DDD jest całkowite oddzielenie czystej logiki biznesowej od implementacji technicznej, umożliwiając programistom myślenie jak eksperci biznesowi.
Podstawową zasadą DDD jest stworzenie wszechobecnego języka. Wszyscy – w tym programiści, testerzy, menedżerowie produktów i eksperci biznesowi – powinni używać ujednoliconego, wspólnego języka opartego na modelu domeny. Oznacza to, że nazwy klas i metod w kodzie muszą bezpośrednio odzwierciedlać koncepcje biznesowe, a nie mgliste terminy, takie jak DataProcessor czy Manager. Na przykład system e-commerce powinien mieć klasę Order i jej metodę place(), zamiast generycznego OrderService, który upycha w niej całą logikę.
Druga podstawowa koncepcja DDD koncentruje się na domenie głównej. W złożonym systemie biznesowym różne subdomeny mają różne wartości biznesowe. Domena główna jest kluczowym czynnikiem sukcesu biznesowego i wymaga największego nakładu pracy projektowej; domena wspólna to wspólna funkcjonalność współdzielona przez wiele subdomen; a domena wspomagająca to infrastruktura obsługująca pozostałe subdomeny.
Praktyka DDD ma dwa wymiary: projektowanie strategiczne i taktyczne. Projektowanie strategiczne koncentruje się na podziale domeny i zdefiniowaniu granic, rozwiązując problem „co zrobić”; projektowanie taktyczne koncentruje się na implementacji konkretnego kodu, rozwiązując problem „jak to zrobić”.
Proces projektowania zorientowanego na domenę
W przypadku dużego systemu próba objęcia wszystkich obszarów biznesowych jednym modelem jest niepraktyczna. Strategiczna część projektowania DDD zapewnia potężne narzędzia do partycjonowania złożonych systemów.
Domena odnosi się do obszaru problemowego, który przedsiębiorstwo musi rozwiązać. Biorąc za przykład system społeczności treści , cała „ społeczność treści ” jest domeną, którą można podzielić na wiele subdomen, takich jak zarządzanie użytkownikami , czytelnicy , płatności i społeczność . Spośród nich społeczność może należeć do domeny głównej, a płatności do domeny pomocniczej.
Podsumowanie: W projektowaniu strategicznym ważne jest określenie, które poddomeny stanowią kluczowe kompetencje przedsiębiorstwa i skoncentrowanie na nich zasobów.
DDD – Diagram poddomeny społeczności treści
To najważniejszy wzorzec strategiczny w modelu DDD (Data Demand and Decision Making). Jasno definiuje on zakres zastosowania modelu, czyli „w jakich granicach to słowo się mieści?”. Na przykład, w kontekście towarów e-commerce, „produkt” ma atrybuty takie jak cena, opis i kategoria; podczas gdy w kontekście logistyki „produkt” koncentruje się bardziej na wadze i objętości.
Każdy ograniczony kontekst jest niezależną „granicą semantyczną”, posiadającą ujednolicony, wspólny model języka i domeny. System jest zatem rozłożony na wiele wysoce spójnych, luźno powiązanych modułów.
Zasada główna: Konteksty ograniczone wyjaśniają swój związek z innymi kontekstami poprzez mapowanie kontekstu, unikając w ten sposób zanieczyszczenia modelu.
[Modelowanie strategii DDD] – Wyznaczanie ograniczonych kontekstów
DDD (Data Dependency Analysis) i architektura mikrousług idealnie do siebie pasują. Dobrze zaprojektowany kontekst ograniczony jest naturalnym kandydatem na mikrousługę. Z drugiej strony, bezmyślne rozbijanie systemu na warstwy techniczne może łatwo doprowadzić do rozproszonego monolitu – usługi mogą być rozdzielone, ale sprzężenie pozostaje. W architekturze mikrousług usługa nie powinna być mniejsza niż agregat i nie większa niż kontekst ograniczony.
W kontekście ograniczonym DDD udostępnia zestaw narzędzi do modelowania taktycznego służących do konstruowania modeli domen.
Encja to obiekt z unikalnym identyfikatorem i cyklem życia. Na przykład, nawet jeśli użytkownik zmieni nazwę, jego unikalny identyfikator pozostaje taki sam i nadal jest tą samą encją. Encje zazwyczaj wykorzystują model bogactwa, w którym zachowania biznesowe są hermetyzowane w obrębie encji.
Obiekty wartości nie posiadają unikalnych identyfikatorów i są rozróżniane wyłącznie na podstawie wartości atrybutów. Zazwyczaj są niezmienne. Na przykład kwota (pieniądze) jest określana przez walutę i wartość; dwie wartości pieniężne o tej samej kwocie i walucie są wymienne. Prawidłowe użycie obiektów wartości może zmniejszyć złożoność systemu; na przykład adresy, adresy e-mail i numery telefonów można modelować jako obiekty wartości.
Agregacja to zbiór powiązanych encji i obiektów wartości, którymi zarządza się jako całością. Element główny agregacji jest elementem centralnym w agregacji i odpowiada za utrzymanie spójności w obrębie agregacji. Na przykład element główny agregacji „Zamówienie” zarządza encjami „Pozycja zamówienia” i „Płatność”; cały dostęp do elementów zamówienia musi odbywać się za pośrednictwem „Zamówienia”.
Zasady projektowania agregatów: Transakcje w obrębie granic agregatu powinny zachowywać spójność; odwołania do innych agregatów powinny odbywać się wyłącznie za pośrednictwem identyfikatorów, unikając bezpośrednich odniesień między agregatami. Agregaty powinny być projektowane tak, aby były jak najmniejsze.
Jest to koncepcja, która początkujący często uważają za mylącą. Usługi domenowe niosą ze sobą zachowania domenowe, których nie można przypisać do encji ani obiektów wartości. Należą one do warstwy domeny, utrzymują jej przejrzystość i nie wymagają szczegółów technicznych. Na przykład usługa TransferService obsługuje transfery między kontami; nie należy do żadnej pojedynczej encji konta, ale stanowi podstawową logikę biznesową.
Usługi aplikacji koordynują obiekty domeny i usługi domeny, obsługują przepływy pracy aplikacji i należą do warstwy aplikacji. Usługi aplikacji są bezstanowe i odpowiadają za harmonogramowanie przypadków użycia, zarządzanie transakcjami oraz uwierzytelnianie bezpieczeństwa, ale nie zawierają reguł biznesowych.
Repozytorium działa jako pomost między warstwą domeny a warstwą infrastruktury. Jest ono zdefiniowane w warstwie domeny jako abstrakcyjny interfejs, podczas gdy warstwa infrastruktury implementuje specyficzną logikę pamięci masowej. Repozytorium udostępnia jedynie metody dostępu poprzez agregację i nie udostępnia szczegółów ORM.
Zdarzenia domenowe to istotne zdarzenia biznesowe występujące w obrębie domeny, które mogą być wykorzystywane do uruchamiania późniejszej logiki biznesowej i oddzielania modułów.
Diagram projektowania taktycznego zorientowanego na domenę
DDD zaleca architekturę warstwową, składającą się zazwyczaj z czterech warstw: warstwy interfejsu użytkownika, warstwy aplikacji, warstwy domeny i warstwy infrastruktury.
Ten komponent odpowiada za interakcję z użytkownikami, odbieranie żądań i zwracanie odpowiedzi. W aplikacji internetowej odpowiada on kontrolerowi, ale odpowiada jedynie za walidację parametrów i formatowanie wyników, nie zawierając logiki biznesowej.
Obiekty domeny są koordynowane w celu realizacji przypadków użycia biznesowego, obsługi granic transakcji, bezpieczeństwa i uwierzytelniania. Usługi warstwy aplikacji pozostają bezstanowe, wywołując jedynie usługi domeny lub metody agregacji głównej i nie zawierają reguł biznesowych.
Rdzeń DDD obejmuje wszystkie reguły i modele biznesowe. Definiuje on korzenie agregatów, encje, obiekty wartości i usługi domenowe, aby zapewnić integralność logiki biznesowej.
Zapewnia wsparcie techniczne w zakresie implementacji, takie jak dostęp do bazy danych, kolejki komunikatów i zewnętrzne wywołania API. Dzięki zasadzie inwersji zależności, warstwa domeny definiuje interfejsy, a warstwa infrastruktury je implementuje, zapewniając pełną izolację między logiką biznesową a implementacją techniczną.
W architekturze warstwowej DDD zależności są kierowane z zewnątrz: warstwa interfejsu użytkownika zależy od warstwy aplikacji, warstwa aplikacji zależy od warstwy domeny, a interfejs warstwy infrastruktury jest definiowany przez warstwę domeny poprzez inwersję zależności. Warstwa domeny nie jest zależna od żadnej konkretnej struktury ani technologii, co pozwala na zastąpienie podstawowej logiki biznesowej alternatywnymi technologiami bez konieczności modyfikacji.
W praktycznej implementacji DDD (Domain-Driven Design) wizualizacja jest kluczowym krokiem w budowaniu konsensusu przez zespoły. Niezależnie od tego, czy chodzi o nakreślenie ograniczonego kontekstu w fazie projektowania strategicznego, czy o konstrukcję modelu domeny w fazie projektowania taktycznego, przejrzyste diagramy są niezbędne. ProcessOn, jako profesjonalne narzędzie do tworzenia diagramów online, może skutecznie wspierać kompleksową wizualizację procesów w architekturach DDD.
1. Przejdź na stronę swojego profilu ProcessOn i utwórz „Schemat blokowy” lub wyszukaj słowa kluczowe, takie jak projekt architektury DDD, w społeczności szablonów.
2. Po lewej stronie, w sekcji „Więcej grafiki”, możesz wybrać kategorie graficzne, takie jak schematy blokowe i diagramy UML, które chcesz dodać do biblioteki graficznej. Przeciągnij i upuść kształty, takie jak prostokąty i okręgi, z biblioteki graficznej na obszar roboczy i użyj linii ze strzałkami, aby połączyć różne elementy i wyrazić zależności.
3. Po wybraniu jednego lub większej liczby elementów górny pasek narzędzi może używać różnych kolorów, aby odróżniać poszczególne poziomy modelu, a także umożliwiać dokonywanie zmian w układzie, na przykład wyrównywanie grafiki i ustawienia warstw.
4. Po ukończeniu diagramu możesz kliknąć przycisk „Udostępnij współpracę” w prawym górnym rogu, aby udostępnić diagram architektury DDD współpracownikom lub klientom w celu ciągłej iteracji modelu. Możesz go również wyeksportować jako obraz o wysokiej rozdzielczości, plik PDF, SVG lub inny format do wykorzystania w przyszłości.
Projektowanie zorientowane na domenę to nie tylko zestaw wzorców technicznych czy specyfikacji architektonicznych; to rewolucja w myśleniu i systematyczna metodologia radzenia sobie z podstawową złożonością oprogramowania. Uczy nas, że rozwój oprogramowania nie zaczyna się od tworzenia tabel, ale od zrozumienia biznesu.
Strategiczne definiowanie granic domen i taktyczne projektowanie wysoce spójnego modelu domen, w połączeniu z architekturą warstwową, która pozwala odizolować logikę biznesową od implementacji technicznej, pozwala DDD znacząco poprawić łatwość utrzymania i skalowalność złożonych systemów biznesowych. Szczególnie w erze mikrousług, metoda partycjonowania ograniczonego kontekstu, oferowana przez DDD, stanowi najlepszą praktykę w zakresie naukowego dekomponowania mikrousług.
Bezpłatny internetowy schemat blokowy mapy myśli do współpracy
