Często widzę ten termin w kontekście architektury oprogramowania („model domeny”, „projektowanie oparte na domenie” itp.). Znalazłem go w Google, ale dostaję mnóstwo różnych definicji. Więc co to tak naprawdę jest?

Słowo „domena” w książce Domain Driven Design autorstwa Erica Evansa ma określone znaczenie. Właśnie o to chodzi w oprogramowaniu.

Evans idzie jednak dalej. Jego zdaniem istnieją subdomeny nawet z tym samym oprogramowaniem. I to jest część książki, która dotyczy „projektowania strategicznego”.

Istnieją trzy „domeny”: domena podstawowa, domena wspierająca i domena ogólna. Czasami nazywa je subdomenami.

Evans bardzo troszczy się również o rzeczywistą działalność związaną z oprogramowaniem, a książka jest skierowana nie tylko do programistów, ale także architektów i menedżerów, którzy muszą zobaczyć, jak oprogramowanie i firma mogą współpracować, i właśnie tym zajmuje się przy omawianiu projektu strategicznego i te subdomeny.

Tak więc podstawową domeną jest część oprogramowania, która reprezentuje zarówno przewagę konkurencyjną, jak i „rację bytu” oprogramowania. To część oprogramowania, dlatego klient kupiłby oprogramowanie w porównaniu z innym oprogramowaniem. Zwykle Evans uważa to za domenę zawierającą najmniejszy procent kodu. Możesz uznać to za najważniejsze 20%. Jest to część, której tak naprawdę nie można kupić z półki i może to być tylko pojedynczy moduł lub składnik całego oprogramowania.

Domena wspierająca jest nadal ważna i może być unikalna dla organizacji, ale nie jest tak ważna jak domena podstawowa. Bez tego oprogramowanie nie będzie tak wartościowe, a rdzeń na nim polega. Może to być wiele modułów w oprogramowaniu, które sam napisałeś i które wykonują ważne, ale wspomagające funkcje do samego rdzenia.

Domena ogólna jest najmniej niestandardową i w pewnym sensie najmniej istotną częścią oprogramowania. Być może napisałeś go w domu, ale bardziej efektywne może być po prostu kupienie go z półki lub użycie dobrze znanego oprogramowania typu open source. Ta część systemu prawdopodobnie nie jest specyficzna dla Twojej ogólnej domeny, więc na przykład, czy masz system wysyłkowy, który kieruje paczki, czy system dokumentacji medycznej, który zarządza pacjentami, domena ogólna jest częścią tych systemów, które są wspólne i po prostu po prostu trzeba tam być, żeby w ogóle funkcjonować. Prawdopodobnie stanowi to większość całego systemu, ale niekoniecznie.

Z perspektywy biznesowej ważne jest, aby zdecydować, jaka jest Twoja domena podstawowa i skoncentrować tam swoje zasoby programistyczne. Evans ma wiele filmów, szczególnie na stronie InfoQ, gdzie wyjaśnia te pojęcia bardziej szczegółowo.

Chociaż więc często mówimy o „domenie” w oprogramowaniu, w przypadku DDD nie jest to tak proste, jak mogłoby się wydawać.

Powinienem zauważyć, że koncepcje DDD niekoniecznie istnieją w szerszej społeczności oprogramowania. Inni programiści, autorzy i ludzie produktu mogą mieć różne pomysły i definicje, niektóre bardziej subtelne, a inne mniej. Nawet inni autorzy, którzy pisali o DDD, mogą przeglądać te koncepcje w książce Evansa, ale uważam, że są one nadal przydatne podczas pisania i planowania projektu oprogramowania.

Domena jest kontekst w świecie rzeczywistym, w której próbujesz rozwiązać problem przy użyciu oprogramowania. Każda domena zawiera wiedzę specjalistyczną, słownictwo i narzędzia, które są częścią tej domeny.

Konkretnym przykładem domeny może być coś takiego jak „zautomatyzowana obróbka skomplikowanych części przy użyciu szybkoobrotowego noża”. Oprogramowanie i sprzęt komputerowy system, który realizuje ten nazywany jest CNC młyn .

Innym przykładem domeny jest dział księgowości w korporacji.

Dalsze czytanie
Ograniczony kontekst Martina Fowlera

Oznacza to po prostu problematyczne miejsce, w którym pracujesz. Na przykład, jeśli tworzysz witrynę handlu elektronicznego, twoją domeną byłby „handel elektroniczny” i obejmowałby procesy związane z praktykami sprzedażowymi klienta / firmy. Tak więc model domeny byłby czymś, co reprezentowałoby produkt, fakturę lub zapis wysyłkowy.

Domain jest obszarem wiedzy. Można to uznać za działanie, w którym istnieją problemy rozwiązane przez oprogramowanie. ( Wiki , Społeczność DDD )

Eric Evans w swojej książce używa transportu ładunków, aby wyjaśnić, czym jest DDD. W jego przykładzie domena polega na wysyłce . W jaki sposób ładunek jest przemieszczany, zarządzany, wysyłany i śledzony itp. Obejmuje własne, szczegółowe zasady, język i procesy. Będą one tworzyć modele domen, obiekty, usługi i tak dalej.

Kiedy tworzysz aplikację, będziesz mieć jakąś autoryzację, tak jak w prawdziwym świecie wysyłki, nie każdy ma dostęp do magazynów. W jaki sposób użytkownicy są autoryzowani i w jaki sposób udzielane są uprawnienia, mogą znajdować się poza domeną , ponieważ informacje mogą nie być istotne dla wysyłki ładunku.

Po prostu: domena jest miejscem, w którym prowadzisz działalność . Jeśli Twoja firma wysyła ładunki - przesyłka będzie Twoją domeną. Jeśli Twoja firma zajmuje się uwierzytelnianiem i autoryzowaniem personelu, będzie to Twoja domena.

Z projektu opartego na domenie: radzenie sobie ze złożonością w sercu oprogramowania , Eric Evans:

Każde oprogramowanie wiąże się z pewną aktywnością lub zainteresowaniami użytkownika. Dziedziną, do której użytkownik stosuje program, jest domena oprogramowania.

Domena programu rezerwacji linii lotniczych obejmuje prawdziwych ludzi wsiadających do prawdziwych samolotów.

Domeną programu księgowego są pieniądze i finanse.

Domeną systemu kontroli kodu źródłowego jest sam rozwój oprogramowania.

Model domeny jest zatem „rygorystycznie zorganizowaną i selektywną abstrakcją” wiedzy w głowie eksperta w dziedzinie.

Palermo, opisując architekturę cebuli, przedstawił to streszczenie

W samym centrum widzimy model domeny, który reprezentuje kombinację stanu i zachowania, która modeluje prawdę dla organizacji.

Fowler z kolei oferuje

Model obiektowy domeny, który obejmuje zarówno zachowanie, jak i dane.

Jeśli patrzysz na nowsze definicje, bardziej prawdopodobne jest, że natrafisz na odniesienia, że model domeny i model danych są różne . Nie uważam, że zmiana znaczenia jest bardziej zmianą nacisku - modelowanie zachowań (sposób, w jaki dane zmieniają się w odpowiedzi na informacje spoza modelu) ma większą złożoność i różnorodność niż różne sposoby zapisywania rzeczy .

Ponieważ prawdopodobnie masz już pojęcie o domenie, myślę, że następnym krokiem, który podejmiesz, jest próba zdefiniowania subdomeny, modelu domeny i, co ważniejsze, ograniczonego kontekstu.

Zaczynam od umieszczenia mojej perspektywy domeny.

Domena

Domena to rzeczywistość, w której żyjemy: jej byty, ich zachowanie, prawa, których przestrzegają. Istniał przed nami i będzie istniał po nas, w takiej czy innej formie. Jego istnienie nie zależy od naszej świadomości. Marketingowcy wymyślają nowe funkcje i przeprowadzają analizy rynku, menedżerowie kluczowych klientów komunikują się z klientami, twórcy oprogramowania automatyzują procesy biznesowe. Dlatego domena nazywa się przestrzenią Problem.

Subdomeny

DDD oznacza rozkład domen na subdomeny, aby ułatwić ich modelowanie i zrozumienie. Sam fakt, że prowadzisz firmę, dowodzi, że istnieje co najmniej jedna dominująca wartość biznesowa. Ten, którym zarabiasz pieniądze. Ten, dla którego rozpoczęliśmy naszą działalność. Nawet jeśli nie znasz takiego słowa, jak „domena podstawowa”, nadal jest ono obecne. To samo dotyczy subdomen: prawdopodobnie będziesz potrzebować księgowości, zasobów ludzkich, wsparcia technicznego - ale jest to kwestia drugorzędna.

Model domeny

Nie ma potrzeby modelowania wyodrębnionych subdomen w całości. W każdej subdomenie, którą jesteśmy zainteresowani, jest pewien zestaw reguł. Zestaw reguł w niektórych subdomenach, który jest niezbędny do osiągnięcia określonego wyniku biznesowego, nazywa się modelem.

Ograniczone konteksty

Najważniejsze jest to, że ograniczony kontekst jest logiczną granicą.

Kiedy zdefiniowane są zarówno subdomeny, jak i domena podstawowa, nadszedł czas na wdrożenie kodu. Ograniczony kontekst określa namacalne granice zastosowania niektórych subdomen. Jest to obszar, w którym pewna poddomena ma sens, a inne nie. Może to być rozmowa, prezentacja, projekt kodu z fizycznymi granicami określonymi przez artefakt.

Co dalej?

Jeśli interesuje Cię, w jaki sposób koncepcja kontekstu ograniczonego koreluje z koncepcją poddomeny, jak definiować poddomeny i konteksty ograniczane, jak reprezentować komunikację między nimi oraz jak organizować zespoły z myślą o tych koncepcjach, prawdopodobnie zainteresowałbyś się tym dalsze czytanie .