Предвижда се, че „архитектурата на микроуслугите“ и управляваният от домейн дизайн (DDD) ще продължат да набират значителна популярност в разработката на софтуер. Комбинирането на тези мощни подходи дава възможност на екипите да изграждат мащабируеми, поддържаеми, съобразени с бизнеса системи.
В тази статия ще проучим ключовите принципи и стъпки, включени в разработването на DDD-ориентирани микроуслуги, което ви позволява да използвате предимствата и на двете парадигми. Нека се задълбочим в тези концепции, използвайки „Bit“ като референция.
Какво е управляван от домейн дизайн (DDD)?
„Дизайн, управляван от домейн“ (DDD) е подход към разработката на софтуер, който набляга на софтуер за моделиране въз основа на домейна, който обслужва. Това включва разбиране и моделиране на домейна или проблемното пространство на приложението, насърчавайки тясното сътрудничество между експертите в областта и разработчиците на софтуер. Това сътрудничество създава споделено разбиране на домейна и гарантира, че разработеният софтуер е в тясно съответствие с неговите сложности.
Какво представляват микроуслугите?
От друга страна, микроуслугите са архитектурен стил, който организира приложение в малки, слабо свързани и независимо внедряеми услуги. Всяка микроуслуга е насочена към специфични бизнес възможности и може да бъде разработена, внедрена и мащабирана независимо. Те насърчават модулността, мащабируемостта и гъвкавостта в разработката на софтуер.
Защо трябва да комбинираме DDD с микроуслуги?
Комбинирането на DDD с архитектура на микроуслуги може да бъде много полезно за изграждане на сложни, мащабируеми и поддържаеми софтуерни системи. DDD и микроуслугите се допълват взаимно и адресират различни аспекти на разработката на софтуер, което ги прави мощна комбинация. Ето основните причини, поради които комбинирането на DDD с микроуслуги е изгодно:
- Ограничени контексти и граници на микроуслуги: DDD въвежда концепцията за ограничени контексти, която дефинира границите на модел на домейн и капсулира неговата логика. Тези ограничени контексти са в съответствие с идеята за микроуслуги, където всяка микроуслуга представлява специфичен ограничен контекст. Това привеждане в съответствие помага при определянето на ясни и независими отговорности за всяка микроуслуга, насърчавайки по-добра модулност и разделяне на проблемите.
- Децентрализирано управление на данни: В микроуслугите всяка услуга носи отговорност за своите данни. Акцентът на DDD върху агрегатите, обектите и стойностните обекти насърчава децентрализиран подход за управление на данни, при който всяка микроуслуга има свое хранилище за данни, което съответства на нейния ограничен контекст. Това изолиране на данни е в съответствие с принципите на DDD и подобрява автономността на услугата.
- Разработка, управлявана от модел: DDD насърчава задълбочено разбиране на домейна и неговата сложност. Чрез прилагането на DDD разработчиците могат да създадат богат модел на домейн, който улавя тънкостите на бизнес домейна. Този подход, управляван от модел, гарантира, че всяка микроуслуга има добре дефинирана и фокусирана върху домейна цел, което води до по-поддържаема и изразителна система.
- Вездесъщ език: DDD се застъпва за използването на вездесъщ език, който се споделя между експерти по домейни и разработчици. Когато се комбинира с микроуслуги, вездесъщият език улеснява по-добрата комуникация между екипите, отговорни за различни микроуслуги. Осигурява общо разбиране на концепциите на домейна и насърчава сътрудничеството.
- Мащабируемост и слабо свързване: Микроуслугите предоставят присъща мащабируемост поради децентрализираната си природа. Акцентът на DDD върху дефинирането на агрегати и ограничени контексти позволява на микроуслугите да бъдат независимо мащабируеми, намалявайки зависимостите и насърчавайки слабото свързване между услугите.
- Еволюционна архитектура: И DDD, и микроуслугите се застъпват за еволюционна архитектура. DDD позволява моделът на домейна да се развива с променящите се бизнес изисквания, докато модулната природа на микроуслугите позволява на отделните услуги да се развиват независимо, без да засягат цялата система.
- Непрекъснато доставяне и внедряване: По-малките и независими кодови бази на Microservices улесняват по-бързото и по-често внедряване. Акцентът на DDD върху ясните граници и модулния дизайн гарантира, че промените в една микроуслуга имат минимално въздействие върху други, което прави непрекъснатата доставка и внедряване по-лесни за постигане.
- Екипна автономия: Чрез привеждане в съответствие на микроуслугите с ограничени контексти, екипите могат да поемат собственост върху отделни микроуслуги, насърчавайки екипната автономност. Всеки екип може да се съсредоточи върху специфичния си домейн и да приложи ефективно бизнес логиката, което води до подобрена производителност.
Въпреки че комбинацията от DDD и микроуслуги предлага много предимства, важно е да се отбележи, че прилагането на двата подхода изисква внимателно разглеждане и разбиране на домейна. Изграждането на успешна система, използваща DDD и микроуслуги, изисква съвместни усилия между експерти по домейни, разработчици и заинтересовани страни за постигане на добре проектирана, мащабируема и поддържаема архитектура.
Как микроуслугите се вписват в методологията на DDD?
DDD подчертава софтуера за моделиране въз основа на домейна, който обслужва.
Ние изследваме основните концепции на DDD, включително ограничени контексти, агрегати, обекти, стойностни обекти и домейн услуги. Като разберете тези принципи, можете ефективно да идентифицирате границите на вашите микроуслуги и да ги проектирате около бизнес домейните, които представляват.
Нека се задълбочим в основните принципи и стъпки в разработването на DDD-ориентирани микроуслуги с пример за приложение за електронна търговия
Внедрете DDD ориентирани микроуслуги
Архитектурата на микроуслугите предлага начин за структуриране на приложение като колекция от слабо свързани услуги, където всяка услуга работи независимо в своя процес и комуникира чрез леки механизми. В нашия пример за електронна търговия всеки ограничен контекст може да бъде имплементиран като отделна микроуслуга.
Например, можем да имаме микроуслуги, посветени на „Управление на поръчки“, „Продуктов каталог“, „Обработка на плащания“ и „Управление на потребители“. Bit поддържа този подход, като предоставя инструменти за създаване и управление на микроуслуги чрез разработка, базирана на компоненти.
1. Разбиране на домейна
В DDD първоначалната стъпка включва задълбочено разбиране на домейна. Това налага сътрудничество с експерти в областта за идентифициране на ключови бизнес концепции, взаимоотношения и поведение.
В нашия пример [основният домейн] (общи поддомейни) може да бъде „Продуктов каталог“. Този обект служи като основен градивен елемент на нашата система, капсулиращ поведението и състоянието. Както в горното изображение, продуктовият каталог е маркиран като „Основен поддомейн“, който представлява основната част от домейна. В този случай, защото това е, с което клиентите ще взаимодействат. Други поддомейни бяха класифицирани като поддръжка и общи.
За да улесни тази стъпка, Bit предлага платформа за сътрудничество, където експертите и разработчиците на домейни могат да си сътрудничат за дефиниране и документиране на модели на домейни, улавяне на бизнес правила и споделяне на знания. Функциите за сътрудничество на Bit, включително споделени работни пространства, контрол на версиите и поддръжка на документация, насърчават ефективна комуникация и споделяне на знания между експерти по домейни и разработчици.
Източник: https://bit.cloud/bit/evangelist/sections/build-together?example=5ee51e53c166fb0019182a29
Поддържани поддомейни функционират като спомагателни домейни в рамките на цялостната система. На практика вие дефинирате ограничен контекст за тях и създавате специално приложение, което служи като поддържаща система за приложението на основния домейн. Въпреки че поддържат, тези приложения поддържат свой собствен различен модел.
От друга страна, [Общи поддомейни](Общи поддомейни) споделят прилики с поддържащите поддомейни, но със значителна разлика. Те предлагат решения, които са толкова гъвкави, че могат да се използват не само в конкретния домейн, за който са създадени, но и в други домейни. Например, едно добре проектирано „Приложение за контрол на достъпа“ може лесно да бъде преназначено, за да поддържа домейни извън електронната търговия. Точно затова те се наричат генерични поддомейни.“
2. Ограничени контексти
При дизайн, управляван от домейн (DDD), домейнът е разделен на „ограничени контексти“, които действат като логически граници, капсулиращи специфични области на домейн. Всеки ограничен контекст представлява отделна подсистема в приложението.
Микроуслугите се подравняват хармонично с ограничените контексти в DDD, тъй като предлагат естествен подход за внедряване и разгръщане на всеки контекст като индивидуална услуга.
В нашето приложение за електронна търговия може да имаме ограничени контексти като „Поръчка“, „Продуктов каталог“, „Плащане“, Наличности, Доставка и „Удостоверяване и оторизация на управлението на потребителите“. Bit улеснява предоставянето на инструменти за дефиниране и управление на границите на ограничени контексти. Диаграмата по-долу изобразява основните контексти на приложението за електронна търговия. С подхода за разработка, управляван от компоненти на Bit, разработчиците могат да капсулират и управляват функционалността на всеки ограничен контекст като независими компоненти. Тези компоненти могат впоследствие да бъдат внедрени като микроуслуги.
3. Дизайн на агрегата
Агрегатите служат като граници на последователност в рамките на домейна, капсулирайки клъстери от свързани обекти и стойностни обекти. Те гарантират последователност на данните и установяват ясни граници за налагане на бизнес правила.
- Как се взема решение за агрегати?
Вземането на решение за агрегати в DDD включва идентифициране на границите на последователност и интегритет на транзакцията в рамките на вашия модел на домейн. Агрегатите са клъстери от свързани обекти и стойностни обекти, които се третират като единична единица, като се гарантира, че промените в една част от агрегата поддържат последователността на цялото.
- Има ли ключови характеристики, които определят даден агрегат?
Да, има ключови характеристики, които определят агрегат в DDD. Агрегатът е основен градивен елемент в DDD, представляващ сплотена единица от обекти на домейн, които се третират като едно цяло с добре дефинирани граници. Ето основните характеристики, които определят един агрегат:
- Граница на съгласуваност: Съвкупността представлява граница на съгласуваност в домейна. Агрегатът гарантира, че състоянието на неговите вътрешни обекти остава последователно и валидно.
- Корен на агрегата: Всеки агрегат има определен „корен на агрегата“, който действа като входна точка към агрегата.
- Граница на транзакция: Промените в агрегат се правят в рамките на една транзакция. Цялата съвкупност се третира като единична единица работа, което гарантира, че или всички промени са успешни, или нито една.
- Енкапсулиране: Вътрешната структура на агрегата е скрита от външни обекти.
- Налагане на инварианти: Агрегатите налагат инварианти, които са правилата и ограниченията, които трябва да са валидни в рамките на агрегата. Инвариантите гарантират, че агрегатът остава във валидно и последователно състояние по време и след всяка операция.
- Управление на жизнения цикъл: Агрегатите управляват жизнения цикъл на своите вътрешни обекти. Например създаването, актуализирането и изтриването на обекти и стойностни обекти трябва да се извършва чрез общия корен, който поддържа контрол върху тези действия.
- Граница за комуникация: Агрегатите служат като граници за комуникация и съгласуваност между различните части на модела на домейна. Промените в един агрегат не засягат директно други агрегати, което помага за поддържане на модулността и намаляване на свързването.
- Грануларност: Агрегатите трябва да имат подходяща грануларност, което означава, че не трябва да са нито твърде големи, нито твърде малки. Те трябва да бъдат проектирани да управляват смислен набор от свързани концепции и операции на домейна.
Разбирането и придържането към тези ключови характеристики на агрегатите е от решаващо значение за успешното прилагане на принципите на DDD и изграждането на добре структурирани модели на домейн в сложни софтуерни системи.
В DDD микроуслугите могат да се приведат в съответствие с агрегатите чрез внедряване на всеки агрегат като отделна микроуслуга. В нашия пример агрегатът „Поръчка“ може да включва обекти като „Елемент за поръчка“, „Клиент“ и „Адрес за доставка“.
Bit улеснява този процес, като предлага инструменти за проектиране и управление на агрегати като компоненти за многократна употреба. Разработчиците могат да дефинират агрегатите като компоненти в Bit и да използват неговите функции за управление на версии и зависимости, за да осигурят последователност и модулност в микроуслугите.
## 4.Комуникация и интеграция
Комуникацията и интеграцията между услугите са жизненоважни в архитектурата на микроуслугите. Услугите трябва да си взаимодействат и да обменят информация, за да изпълняват бизнес процеси.
5.Внедряване и мащабиране
Микроуслугите предлагат предимството на независимо внедряване и мащабиране, което позволява всяка микроуслуга да бъде разгръщана и мащабирана индивидуално въз основа на нейните специфични изисквания. Тази гъвкавост и мащабируемост са от решаващо значение за съвременното разработване на софтуер.
Заключение
В заключение, разработването на DDD-ориентирани микроуслуги включва цялостно разбиране както на принципите на DDD, така и на архитектурата на микроуслугите.
Чрез приемане на DDD, идентифициране на ограничени контексти и подравняване на микроуслуги с агрегати, можете да конструирате системи, които са мащабируеми, поддържаеми и тясно съобразени с вашите бизнес нужди. От решаващо значение е непрекъснатото итериране и усъвършенстване на вашата архитектура, включвайки опит в областта и обратна връзка. Този итеративен подход гарантира, че вашите микроуслуги се развиват и адаптират с времето, като са в крак с променящите се нужди на вашия бизнес. Като комбинирате силата на DDD и микроуслугите, можете да създадете стабилни и адаптивни софтуерни системи, които движат вашата организация напред.
