Articles

Jak używać wszechobecnego języka do projektowania sterowanego domeną (DDD)? | Teddy Aryono

Poznaj diagram i jego znaczenie. W tym przypadku mamy do czynienia z osobą biznesową (użytkownikiem) i deweloperem w odniesieniu do systemu informatycznego kargo.

Percakapan 1 – Minimalna abstrakcja domeny

Użytkownik 😊 : Więc kiedy zmienimy punkt odprawy celnej, musimy przerobić cały plan trasy.

Deweloper 🤓 : Racja. Usuniemy wszystkie wiersze w tabeli przesyłek z tym id ładunku, następnie przekażemy pochodzenie, miejsce docelowe i nowe miejsce odprawy celnej do Routing Service, a on ponownie wypełni tabelę. Będziemy musieli mieć Boolean w Cargo, abyśmy wiedzieli, że są dane w tabeli wysyłki.

😊 : Usunąć wiersze? OK, nieważne. W każdym razie, jeśli wcześniej nie mieliśmy punktu odprawy celnej, będziemy musieli zrobić to samo.

🤓 : Jasne, za każdym razem, gdy zmienisz miejsce pochodzenia, przeznaczenia lub odprawy celnej (lub wprowadzisz je po raz pierwszy), sprawdzimy, czy mamy dane o przesyłce, a następnie usuniemy je i pozwolimy, aby Routing Service je zregenerował.

😊 : Oczywiście, jeśli stara odprawa celna akurat okazała się właściwa, nie chcielibyśmy tego robić.

🤓 : Och, nie ma problemu. Łatwiej jest po prostu sprawić, by Routing Service powtórzył ładunki i rozładunki za każdym razem.

😊 : Tak, ale to dodatkowa praca dla nas, by zrobić wszystkie wspierające plany dla nowej trasy, więc nie chcemy zmieniać trasy, chyba że cange tego wymaga.

🤓 : Ugh. Cóż, w takim razie, jeśli wjeżdżasz do punktu odprawy celnej po raz pierwszy, będziemy musieli zapytać tabelę, aby znaleźć stary pochodny punkt odprawy celnej, a następnie porównać go z nowym. Wtedy będziemy wiedzieć, czy musimy to powtórzyć.

😊 : Nie będziecie musieli się o to martwić w miejscu pochodzenia lub przeznaczenia, ponieważ trasa zawsze będzie się wtedy zmieniać.

🤓 : Dobrze. Nie będziemy.

Więcej informacji na temat diagramu i planu podróży. To jest metoda, która jest trwała, a jednocześnie wymaga znajomości języka, którym się posługujemy.

Percakapan 2 – Model domeny wzbogacony w celu wsparcia dyskusji

😊 : Więc kiedy zmieniamy punkt odprawy celnej, musimy przerobić cały plan trasy.

🤓 : Racja. Kiedy zmienisz którykolwiek z atrybutów w Specyfikacji Trasy, usuniemy stary Plan Podróży i poprosimy Serwis Trasowy o wygenerowanie nowego na podstawie nowej Specyfikacji Trasy.

😊 : Jeśli wcześniej w ogóle nie określiliśmy punktu odprawy celnej, będziemy musieli to zrobić w tym samym czasie.

🤓 : Jasne, za każdym razem, gdy zmienisz cokolwiek w Specyfikacji Trasy, zregenerujemy Plan Podróży. To dotyczy również wprowadzania czegoś po raz pierwszy.

😊 : Oczywiście, jeśli stara odprawa celna okazała się właściwa, nie chcielibyśmy tego robić.

🤓 : Och, nie ma problemu. Tak, ale to dodatkowa praca dla nas, aby wykonać wszystkie plany wspierające dla nowego planu podróży, więc nie chcemy zmieniać trasy, chyba że zmiana tego wymaga.

🤓 : Oh. Wtedy będziemy musieli dodać pewną funkcjonalność do Specyfikacji Trasy. Następnie, za każdym razem, gdy zmienisz coś w Spec, zobaczymy, czy Plan Podróży nadal spełnia wymagania Specyfikacji. Jeśli nie, zlecimy Routing Service regenerację Planu Podróży.

😊 : Nie będziesz musiał się o to martwić w miejscu pochodzenia lub przeznaczenia, ponieważ Plan Podróży zawsze będzie się wtedy zmieniał.

🤓 : Dobrze, ale będzie nam prościej po prostu robić porównanie za każdym razem. Plan podróży będzie generowany tylko wtedy, gdy Specyfikacja trasy nie będzie już spełniona.

Gambar dibawah ini mengilustrasikan domain experts dan software developers yang sedang berdiskusi. Główną kategorią są programiści oprogramowania (odnoszący się do umiejętności związanych z technologią), a główną kategorią są eksperci domenowi (odnoszący się do umiejętności związanych z użytkownikami, lub mogący pracować w biznesie).

Eksperci domenowi (z tego punktu widzenia są to biznesmeni/użytkownicy) posiadają wiedzę na temat żargonu, który jest używany podczas tworzenia oprogramowania, a także znają żargon używany podczas pracy nad oprogramowaniem.

Poprawiając to, deweloperzy są w stanie rozwijać oprogramowanie, a jednocześnie mają minimalną wiedzę na temat żargonu, który jest używany przez ekspertów w danej dziedzinie (w związku z tym deweloperzy mają minimalną wiedzę na temat świata, w którym żyją).

W tej sytuacji, wszechobecny język jest trudny do opanowania, dlatego eksperci domenowi i deweloperzy mogą używać języka, który jest używany, ponieważ każdy z nich posługuje się żargonem. Istniejąca wiedza jest wykorzystywana w sposób ciągły, np. specyfikacja trasy jest wykorzystywana w sposób ciągły przez origin, destination i custom clearance point (diagram).

Diagram venn jest ilustracją, która pokazuje, jak używać wszechobecnego języka.

.