Що, по відношенню до DDD, є обмеженим контекстом?

Під час роботи над книгою "Впровадження дизайну, керованої доменом" Вона Вернона, я не зміг зрозуміти, що насправді є обмеженим контекстом.

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

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

Мартін Фаулер коротко обговорює ідею обмеженого контексту ( http://martinfowler.com/bliki/BoundedContext.html ), але насправді не з'ясовує проблему.

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

Обмежені контексти та субдомени існують на різних рівнях.

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

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

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

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

Методи дизайну, керованого доменом, допомагають нам робити моделі світу, в якому ми живемо. Ці моделі існують як ідеї у свідомості людей, які беруть участь у проекті.

Оскільки телепатія ще в зародковому стані, ці ідеї передаються між людьми за допомогою слів та фраз.

Слова та фрази можуть бути неоднозначними в найкращі часи. Щоб зменшити неоднозначність, ми використовуємо «контекст», щоб уточнити їх значення.

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

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

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

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

Це якесь - то явне підтвердження, команда, що this phraseв this part of the projectточності означає this thing(а не так , як ви могли б добре подумати, that thing).

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

Це все. Це дуже проста ідея, яка настільки важлива, що про неї написано багато.

Так що так. Обмежений контекст - це буквально межа, «огорожа», яка відрізняє контекст одного піддомену від контексту іншого субдомену в проекті.

Модель та мова субдомену відокремлені від інших моделей та мов, щоб уникнути двозначностей у значенні.

Але, так. Світ не такий простий.

Ви та команда повинні дотримуватися визначеного контексту. Дуже легко бути лінивим і заново уявити собі контекст, щоб вирізати кути під час створення програмного забезпечення.

Також речі взаємодіють з іншими речами і обмежений контекст також повинен взаємодіяти один з одним. Отже, існують різні схеми, які описують, як відбуваються ці взаємодії. Дивіться у книзі Еріка Евана Розділ 14, керований доменом, щодо цих різних моделей: Спільне ядро, Постачальник клієнтів, Конформіст, Антикорупційний шар, Окремі шляхи, Відкрита хост-служба, Опублікована мова.

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

У різних ситуаціях я використовую три різні точки зору, або метафори концепції обмеженого контексту.

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

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

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

Мені дуже подобається цей приклад концепції обмеженого контексту.

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