Цей термін я багато бачу в контексті архітектури програмного забезпечення ("модель домену", "дизайн, керований доменом" тощо). Я переглянув це, але отримую тони різних визначень. То що це насправді?

Слово "домен" у книзі "Дизайн, керований доменом" Еріка Еванса має конкретне значення. Це те, про що йдеться в програмному забезпеченні.

Еванс ходить і далі. На його думку, існують піддомени навіть з тим самим програмним забезпеченням. І це частина книги, яка стосується "Стратегічного дизайну".

Існує три "домени": основний, підтримуючий і загальний домен. Іноді він посилатиметься на них як на піддомени.

Еванс також глибоко піклується про власний бізнес, що стоїть за програмним забезпеченням, і книга орієнтована не лише на розробників, а й на архітекторів та менеджерів, які повинні бачити, як програмне забезпечення та бізнес можуть спільно працювати, і саме цим він переймається, обговорюючи стратегічний дизайн і ці піддомени.

Отже, основний домен - це частина програмного забезпечення, яка представляє як конкурентну перевагу, так і «raison d'etre» програмного забезпечення. Це частина програмного забезпечення, саме тому клієнт купує це програмне забезпечення порівняно з іншим програмним забезпеченням. Зазвичай Еванс розглядає це як домен, що містить найменший відсоток коду. Ви можете вважати це найважливішим 20%. Це частина, яку ви справді не можете купити з полиці, і це може бути лише один модуль або компонент загального програмного забезпечення.

Підтримуючий домен все ще важливий і може бути унікальним для організації, але не є таким важливим, як основний домен. Без нього програмне забезпечення не буде настільки цінним, і ядро ​​покладається на нього. Це можуть бути декілька модулів у програмному забезпеченні, яке ви написали самі, і які виконують важливі, але підтримуючі функції до ядра.

Загальний домен - це найменш спеціальна і в деякому сенсі найменш важлива частина програмного забезпечення. Можливо, ви написали це вдома, але може бути ефективніше просто придбати його з полиці або використовувати добре відоме програмне забезпечення з відкритим кодом. Ця частина системи, ймовірно, не характерна для вашого загального домену, тому, наприклад, чи є у вас система доставки, яка маршрутизує посилки, або система обліку здоров'я, яка керує пацієнтами, загальний домен є частиною цих систем, які є загальними і справедливими. просто потрібно бути там, щоб взагалі функціонувати. Це, ймовірно, складає основну частину системи в цілому, але це не обов'язково.

З точки зору бізнесу важливо вирішити, що є вашим основним доменом, і зосередити свої ресурси на розвитку там. Еванс має багато відео, зокрема на сайті InfoQ, де він детальніше пояснює ці поняття.

Тому, хоча ми часто говоримо про “домен” у програмному забезпеченні, у випадку DDD, це не так просто, як може здатися.

Зазначу, що поняття DDD не обов'язково існують у ширшому програмному середовищі. Інші розробники, автори та люди продукту можуть мати різні ідеї та визначення, деякі більш тонкі, а деякі менші. Навіть інші автори, які писали про DDD, можуть замислитися над цими поняттями в книзі Еванса, але я вважаю, що ці поняття все ще корисні при написанні та плануванні програмного проекту.

Домен є реальним контекстом , в якому ви намагаєтеся вирішити проблему з допомогою програмного забезпечення. Кожен домен має досвід, словниковий запас та інструменти, що входять до цього домену.

Конкретним прикладом домену може бути щось на кшталт "автоматизованої обробки складних деталей за допомогою швидкісного обертового різака". Програмно-апаратний комплекс , який виконує це називається ЧПУ млин .

Іншим прикладом домену є бухгалтерія корпорації.

Подальше читання
обмеженого контексту Мартіна Фаулера

Це просто означає проблемний простір, в якому ви працюєте. Наприклад, якщо ви будували веб-сайт електронної комерції, ваш домен був би "електронною комерцією" і включав би процеси, пов'язані з практикою продажу вашого клієнта / компанії. Таким чином, доменна модель може представляти собою товар, рахунок-фактуру або запис про доставку.

Домен є галузь знань. Це може бути як діяльність, в якій існують проблеми, вирішені вашим програмним забезпеченням. ( Вікі , спільнота DDD )

Ерік Еванс у своїй книзі використовує доставку вантажів, щоб пояснити, що таке DDD. У його прикладі, домен - це все про доставку . Як переміщують, керують, відвантажують та відслідковують вантаж тощо. Він постачається зі своїми специфічними правилами, мовою та процесами. Вони створюватимуть доменні моделі, об’єкти, послуги тощо.

Створюючи додаток, ви матимете певний дозвіл, як і в реальному світі доставки, не кожен може отримати доступ до складів. Як авторизовані користувачі та як надаються дозволи можуть бути поза доменом , оскільки інформація може не стосуватися перевезення вантажу.

Простіше кажучи: домен - це те, де ви ведете бізнес . Якщо ваш бізнес здійснює доставку вантажів - доставка вантажу буде вашим доменом. Якщо ваш бізнес займається автентифікацією та авторизацією персоналу, то це буде ваш домен.

Ерік Еванс від дизайну, керованого доменом: вирішення складності в серці програмного забезпечення :

Кожна програмна програма стосується певної діяльності чи інтересу свого користувача. Тематична область, до якої користувач застосовує програму, - це домен програмного забезпечення.

Домен програми бронювання авіакомпаній включає реальних людей, які отримують реальні літаки.

Домен облікової програми - гроші та фінанси.

Домен системи управління вихідним кодом - сама розробка програмного забезпечення.

Тоді доменна модель - це "жорстко організована та вибіркова абстракція" знань у голові експерта з домену.

Палермо, описуючи архітектуру цибулі, запропонував це резюме

У самому центрі ми бачимо Доменну модель, яка представляє комбінацію стану та поведінки, яка моделює істину для організації.

Фаулер, у свою чергу, пропонує

Об'єктна модель домену, що включає в себе і поведінку, і дані.

Якщо ви переглядаєте новіші визначення, ви, швидше за все, наштовхуєтесь на те, що доменна модель та модель даних відрізняються . Я не вважаю, що зміна значення настільки, як зміна акценту - моделювання поведінки (спосіб зміни даних у відповідь на інформацію поза моделлю) має більшу складність та варіативність, ніж різні способи запису речей .

Оскільки ви, мабуть, вже маєте уявлення про те, що таке домен, я думаю, що наступним кроком, який ви зробите, є спроба визначити субдомен, модель домену та, що ще важливіше, обмежений контекст.

Я все ж починаю з викладу своєї точки зору домену.

Домен

Домен - це реальність, яку ми населяємо: її сутності, їх поведінку, закони, яким вони підкоряються. Він існував до нас і буде існувати після нас, в тій чи іншій формі. Його існування не залежить від нашої обізнаності. Маркетологи придумують нові функції та виконують аналіз ринку, менеджери ключових облікових записів спілкуються з клієнтами, розробники програмного забезпечення автоматизують бізнес-процеси. Ось чому домен називають проблемним простором.

Піддомени

DDD передбачає розкладання домену на піддомени, щоб полегшити їх моделювання та розуміння. Сам факт, що ви ведете бізнес, підказує, що є хоча б одна переважаюча цінність для бізнесу. Той, на якому ви заробляєте гроші. Той, для якого ми розпочали свою справу. Тож навіть якщо ви не знаєте такого слова, як "Основний домен", воно все одно присутнє. Те ж стосується і субдоменів: напевно, вам знадобиться бухгалтерія, людські ресурси, технічна підтримка - але це другорядне значення.

Модель домену

Немає необхідності в повному моделюванні витягнутих піддоменів. У кожному субдомені, який нас цікавить, існує певний набір правил. Набір правил у деякому субдомені, необхідне для досягнення певного бізнес-результату, називається моделлю.

Обмежений контекст

Найголовніше, що обмежений контекст є логічною межею.

Коли обидва субдомени та основний домен визначені, саме час реалізувати код. Обмежений контекст визначає відчутні межі застосовності деякого субдомену. Це область, де певний субдомен має сенс, а інші - ні. Це може бути бесіда, презентація, проект коду з фізичними межами, визначеними артефактом.

Що далі?

Якщо вас цікавить, як обмежена концепція контексту співвідноситься з концепцією субдомену, як визначати субдомени та обмежені контексти, як представляти їх спілкування один з одним та як організувати команди з цими поняттями на увазі, напевно, вам це буде цікаво подальше читання .