Проектиране, управлявано от домейн: Овладяване на ограничените контексти за мащабируем софтуер

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

Какво е ограничен контекст?

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

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

Защо да използваме ограничени контексти?

Използването на ограничени контексти осигурява многобройни предимства при разработката на софтуер:

• Намалена сложност: Чрез разделяне на голям домейн на по-малки, по-управляеми контексти, вие намалявате общата сложност на системата. Всеки контекст може да бъде разбран и поддържан по-лесно.
• Подобрено сътрудничество: Ограничените контексти улесняват по-добрата комуникация между разработчици и експерти по домейн. Всеобхватният език гарантира, че всички говорят на един и същ език в рамките на специфичен контекст.
• Независимо развитие: Екипите могат да работят независимо върху различни ограничени контексти, без да си пречат. Това позволява по-бързи цикли на разработка и повишена гъвкавост.
• Гъвкавост и мащабируемост: Ограничените контексти ви позволяват да развивате различни части на системата независимо. Можете да мащабирате специфични контексти въз основа на техните индивидуални нужди.
• Подобрено качество на кода: Фокусирането върху специфичен домейн в рамките на ограничен контекст води до по-чист и по-лесен за поддръжка код.
• Съответствие с бизнеса: Ограничените контексти често съответстват на специфични бизнес възможности или отдели, което улеснява картографирането на софтуера към бизнес нуждите.

Стратегически DDD: Идентифициране на ограничени контексти

Идентифицирането на ограничени контексти е ключова част от фазата на стратегически дизайн в DDD. То включва разбиране на домейна, идентифициране на основните бизнес възможности и дефиниране на границите на всеки контекст. Ето стъпка по стъпка подход:

1. Изследване на домейна: Започнете с цялостно изследване на проблемния домейн. Разговаряйте с експерти по домейн, прегледайте съществуващата документация и разберете различните бизнес процеси, участващи в него.
2. Идентифициране на бизнес възможности: Идентифицирайте основните бизнес възможности, които софтуерната система трябва да поддържа. Тези възможности представляват основните функции, които бизнесът изпълнява.
3. Търсене на семантични граници: Търсете области, където значението на термините се променя или където се прилагат различни бизнес правила. Тези граници често показват потенциални ограничени контексти.
4. Разгледайте организационната структура: Организационната структура на компанията често може да предостави улики за потенциални ограничени контексти. Различни отдели или екипи могат да отговарят за различни области на домейна. Законът на Конуей, който гласи, че „организациите, които проектират системи, са принудени да създават дизайни, които са копия на комуникационните структури на тези организации“, е изключително релевантен тук.
5. Начертайте карта на контекста: Създайте карта на контекста, за да визуализирате различните ограничени контексти и техните взаимоотношения. Тази карта ще ви помогне да разберете как различните контексти си взаимодействат.

Пример: Система за електронна търговия

Разгледайте голяма система за електронна търговия. Тя може да съдържа няколко ограничени контекста, като например:

• Продуктов каталог: Отговаря за управлението на информацията за продукти, категории и атрибути. Всеобхватният език включва термини като „продукт“, „категория“, „SKU“ и „атрибут“.
• Управление на поръчки: Отговаря за обработката на поръчки, управлението на пратки и обработката на връщания. Всеобхватният език включва термини като „поръчка“, „пратка“, „фактура“ и „плащане“.
• Управление на клиенти: Отговаря за управлението на клиентски акаунти, профили и предпочитания. Всеобхватният език включва термини като „клиент“, „адрес“, „програма за лоялност“ и „информация за контакт“.
• Управление на инвентар: Отговаря за проследяване на нивата на инвентар и управление на местоположенията на склад. Всеобхватният език включва термини като „ниво на склад“, „местоположение“, „точка за пренареждане“ и „доставчик“.
• Обработка на плащания: Отговаря за сигурна обработка на плащания и обработка на възстановявания. Всеобхватният език включва термини като „транзакция“, „разрешение“, „уреждане“ и „данни за карта“.
• Механизъм за препоръки: Отговаря за предоставянето на продуктови препоръки на клиенти въз основа на тяхната история на сърфиране и поведение при покупки. Всеобхватният език включва термини като „препоръка“, „алгоритъм“, „потребителски профил“ и „продуктов афинитет“.

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

Карти на контекста: Визуализиране на взаимоотношенията между ограничените контексти

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

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

Тактически DDD: Интеграционни модели

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

Ето някои често срещани интеграционни модели:

• Споделено ядро: Два или повече ограничени контекста споделят общ модел или код. Това е рисков модел, тъй като промените в споделеното ядро могат да повлияят на всички контексти, които зависят от него. Използвайте този модел пестеливо и само когато споделеният модел е стабилен и добре дефиниран. Например, множество услуги в рамките на финансова институция могат да споделят основна библиотека за изчисляване на валути.
• Клиент-Доставчик: Един ограничен контекст (Клиентът) зависи от друг ограничен контекст (Доставчикът). Клиентът активно оформя модела на Доставчика, за да отговори на своите нужди. Този модел е полезен, когато един контекст има силна нужда да влияе на другия. Система за управление на маркетингови кампании (Клиент) може силно да влияе върху развитието на платформа за данни за клиенти (Доставчик).
• Конформист: Един ограничен контекст (Конформистът) просто използва модела на друг ограничен контекст (Нагоре по веригата). Конформистът няма влияние върху модела на Нагоре по веригата и трябва да се адаптира към неговите промени. Този модел често се използва при интегриране с наследени системи или услуги на трети страни. Едно малко приложение за продажби може просто да се съобразява с модела на данни, предоставен от голяма, утвърдена CRM система.
• Антикорупционен слой (ACL): Слой на абстракция, който стои между два ограничени контекста, превеждайки между техните модели. Този модел защитава долния контекст от промени в горния контекст. Това е решаващ модел при работа с наследени системи или услуги на трети страни, които не можете да контролирате. Например, при интегриране с наследена система за заплати, ACL може да преведе наследения формат на данни в формат, който е съвместим със системата за човешки ресурси.
• Разделни пътища: Два ограничени контекста нямат връзка помежду си. Те са напълно независими и могат да се развиват самостоятелно. Този модел е полезен, когато двата контекста са фундаментално различни и нямат нужда да си взаимодействат. Вътрешна система за проследяване на разходи за служители може да бъде напълно отделена от публично достъпната платформа за електронна търговия.
• Услуга с отворен хост (OHS): Един ограничен контекст публикува добре дефиниран API, който други контексти могат да използват за достъп до неговата функционалност. Този модел насърчава слабото свързване и позволява по-гъвкава интеграция. API трябва да бъде проектиран, като се имат предвид нуждите на потребителите. Услуга за платежен портал (OHS) излага стандартизиран API, който различни платформи за електронна търговия могат да използват за обработка на плащания.
• Публикуван език: Услугата с отворен хост използва добре дефиниран и документиран език (напр. XML, JSON) за комуникация с други контексти. Това осигурява оперативна съвместимост и намалява риска от погрешно тълкуване. Този модел често се използва във връзка с модела на услуга с отворен хост. Система за управление на веригата за доставки излага данни чрез REST API, използвайки JSON Schema, за да осигури ясен и последователен обмен на данни.

Избор на правилния интеграционен модел

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

Често срещани клопки и анти-модели

Въпреки че ограничените контексти могат да бъдат изключително полезни, има и някои често срещани клопки, които трябва да се избягват:

• Голяма топка кал: Неуспешно дефиниране на ограничени контексти и в крайна сметка получаване на монолитна система, която е трудна за разбиране и поддръжка. Това е обратното на това, което DDD цели да постигне.
• Случайна сложност: Въвеждане на ненужна сложност чрез създаване на твърде много ограничени контексти или чрез избор на неподходящи интеграционни модели.
• Преждевременна оптимизация: Опит за оптимизиране на системата твърде рано в процеса, преди пълното разбиране на домейна и взаимоотношенията между ограничените контексти.
• Игнориране на закона на Конуей: Неуспешно съгласуване на ограничените контексти с организационната структура на компанията, водещо до проблеми с комуникацията и координацията.
• Прекомерна зависимост от споделеното ядро: Използване на модела на споделено ядро твърде често, което води до тясно свързване и намалена гъвкавост.

Ограничени контексти и микроуслуги

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

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

Практически примери от цял свят

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

• Глобална логистика: Многонационална логистична компания може да има отделни ограничени контексти за *Проследяване на пратки* (обработка на актуализации на местоположението в реално време), *Митническо освобождаване* (справяне с международни разпоредби и документация) и *Управление на складове* (оптимизиране на съхранението и инвентара). „Артикулът“, който се проследява, има много различни представяния във всеки контекст.
• Международно банкиране: Глобална банка може да използва ограничени контексти за *Банкиране на дребно* (управление на индивидуални клиентски сметки), *Търговско банкиране* (обработка на бизнес заеми и транзакции) и *Инвестиционно банкиране* (справяне с ценни книжа и търговия). Дефиницията на „клиент“ и „сметка“ би се различавала значително в тези области, отразявайки разнообразните регулации и бизнес нужди.
• Многоезично управление на съдържание: Глобална новинарска организация може да има отделни ограничени контексти за *Създаване на съдържание* (авторинг и редактиране на статии), *Управление на преводи* (обработка на локализация за различни езици) и *Публикуване* (разпространение на съдържание по различни канали). Концепцията за „статия“ има различни атрибути в зависимост от това дали се създава, превежда или публикува.

Заключение

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

Практически съвети

1. Започнете от малко: Не се опитвайте да дефинирате всичките си ограничени контексти наведнъж. Започнете с най-важните области на домейна и повтаряйте, докато научавате повече.
2. Сътрудничете с експерти по домейн: Ангажирайте експерти по домейн по време на целия процес, за да гарантирате, че вашите ограничени контексти точно отразяват бизнес домейна.
3. Визуализирайте вашата карта на контекста: Използвайте карта на контекста, за да комуникирате взаимоотношенията между вашите ограничени контексти на екипа за разработка и заинтересованите страни.
4. Непрекъснато рефакторирайте: Не се страхувайте да рефакторирате вашите ограничени контексти, докато разбирането ви за домейна се развива.
5. Приемете промяната: Ограничените контексти не са заковани. Те трябва да се адаптират към променящите се бизнес нужди и технологични постижения.