Ограничените контексти определят логическа граница на бизнес домейн, където се използва последователен повсеместен език. Въпреки че ограничените контексти се развиват независимо, те все още трябва да си сътрудничат, за да създадат система, която ще осигури стойност за бизнеса.

Когато за първи път започнах с DDD, едно нещо продължаваше да ме тормози. Какъв е най-добрият начин, по който ограничените контексти трябва да си сътрудничат? Трябва ли да се развиват независимо и да дублират компоненти, както намерят за добре? Трябва ли да имат споделен набор от класове, които използват? Трябва ли да защитите ограничен контекст от договорите на друг? Признавам, че тогава бях малко наивен и обикновено избирах черно-белия подход. Въпреки това, когато узрях и прочетох повече ресурси, заключих, че няма 100% правилен или грешен начин за сътрудничество в ограничен контекст. Всичко се свежда до вашите бизнес нужди и колко добре комуникират хората, работещи в различни контексти. В тази статия ще се опитам да споделя някои общи модели за комуникация в ограничен контекст и кога трябва да ги вземете предвид.

Партньорство

В този модел интеграцията между ограничените контексти се извършва в движение. Ако даден екип реши, че трябва да модифицира своя API, той ще информира другите екипи и те ще направят необходимите промени. Без драма, без суетене. В този сценарий никой екип не диктува вездесъщия език, който се използва. Те си сътрудничат и намират най-подходящото решение. Екипите също така работят заедно за разрешаване на всеки интеграционен конфликт, който може да възникне бързо.

Този модел работи най-добре за зрели екипи, които комуникират добре. Обратно, екипи, разпределени в големи географски райони, може да намерят този подход за предизвикателство, тъй като комуникацията и синхронизацията са по-сложни и отнемащи време.

Споделено ядро

В реалния живот има много ситуации, в които някои модели се използват в много ограничени контексти. Когато това се случи, имате две възможности: дублиране или споделяне.

С помощта на модела за споделяне създавате компоненти, използвани от множество ограничени контексти. Когато ядрото за споделяне бъде модифицирано, то засяга всички ограничени контексти, които зависят от него. По този начин се създава силно свързване.

Има няколко неща, които можете да направите, за да смекчите този недостатък:

· Поддържайте споделеното ядро ​​малко, възможно най-малко

· В идеалния случай само структури от данни, които се споделят между ограничени контексти, трябва да се съхраняват в споделеното ядро

· Непрекъсната интеграция — всеки път, когато споделеното ядро ​​се промени, ограничените контексти също трябва да бъдат актуализирани и проверени за съответствие

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

Доставчик-Потребител

Има много ситуации, при които един ограничен контекст предоставя данни или услуги на друг. Ние наричаме контекста, който предоставя данни/услуги доставчик или ограничен контекст нагоре по веригата. Този, който зависи от тези данни/услуги, се нарича потребителски или ограничен контекст надолу по веригата. Когато това се случи, един от ограничените контексти обикновено е по-важен от бизнес гледна точка.

Ако доставчикът е по-важен (неговият екип има повече власт за вземане на решения), тогава екипът, който го притежава, ще диктува договора за интеграция. Това е подход „вземи или остави“. Контекстът, обвързан с доставчика, определя интеграционния договор и потребителите трябва да се адаптират. В този сценарий можете да изберете конформисткия модел или ACL модела.

Конформист

Ако екипът надолу по веригата може да приеме и се адаптира към модела на екипа нагоре по веригата, тяхната връзка с ограничен контекст се нарича конформистка.

Може би се чудите защо един отбор би дал контрол и автономия на друг? Ако договорът за интеграция, предоставен от екипа нагоре по веригата, се придържа към признат от индустрията стандарт или ако е достатъчно добър за екипа надолу по веригата, тогава това може да е прагматичен избор. Егото е опасно нещо в разработката на софтуер. Трябва да знаеш кога да го пуснеш.

Антикорупционен слой (ACL)

Когато ограниченият контекст надолу по веригата е основен поддомейн (жизнено важен за бизнеса), конформисткият подход не работи, дори ако мащабът на властта все още е наклонен към екипа нагоре по веригата.

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

Казано по-просто, антикорупционният слой (ACL) е само междинно положение между договора за външна интеграция и вътрешния модел на домейн на контекста, ограничен от потребителя. Целта му е да защити бизнес логиката от външен шум и да поддържа нещата валидни и последователни.

Open-Host услуга (OHS)

Този интеграционен модел се отнася за случаите, при които балансът на силите е в полза на потребителите. Доставчикът отделя логиката си за внедряване от публичния си API, за да обслужва по-добре потребителите. Това е обратното на ситуацията с ACL.

Публичният интерфейс на доставчика не трябва да отговаря на неговия вездесъщ език. Вместо това договорът за интеграция е изграден така, че да обслужва най-добре ограничените контексти надолу по веригата.

Обичайно е услугите нагоре по веригата да излагат множество версии на договора за интеграция. Това позволява на потребителите да изберат договора, който е най-подходящ за техните нужди, и постепенно да мигрират към по-нови версии.

Различни пътища

Понякога цената на интегрирането на ограничени контексти надхвърля времето, необходимо за дублиране на компоненти. Ако случаят е такъв, дублирането е прагматичен избор. Дублирането на компоненти, дори ако те може да са еднакви за множество ограничени контексти, също е осъществимо, ако ефективната комуникация между екипите не е възможна. Използвайки този подход, екипите могат да развиват своя ограничен контекст независимо.

Заключение

Надявам се, че съм ви убедил, че няма правилен или грешен модел на интеграция между ограничени контексти. Всеки подход има плюсове и минуси и е подходящ за определен сценарий.

Също така съм наясно, че моето представяне на тези интеграционни модели не е дълбоко гмуркане в тази тема, а добра отправна точка, особено ако сте нов практикуващ DDD.