DDD (Domain driven design) или предметно-ориентированное проектирование.
Бывает, что появление нового микросервиса обязано техническими причинами, нежели обусловлено бизнесом. Например, микросервис делится на несколько, потому что в памяти перестают умещаться все кэши.
И хотя вроде бы целью разделения и было уменьшение связанности, но бизнес задачи как-то не ложатся и, например, структура Order живет в тысяче мест и везде значит что-то свое. Потом можно все это дело достаточно много рефакторить, чтобы привести в порядок.
Ключом для избегания таких проблем является подход к проектированию на основе предметной области. Суть его состоит в том, чтобы технические решения описывали бизнесовые сущности, так называемые домены (domains). Эти домены иерархичны — нижние домены описывают более высокоуровневые. Команды могут брать ответственность за домены с понятным скоупом ответственности.
Реализация функциональности затрагивает определенные домены, значит, понятно в кого идти и сколько делать.
Примеры доменов: заказ, клиент, исполнитель; счет, платеж, карта; пицца, курьер, пиццерия.
Примеры технических решения на основе доменов: система управления заказами, система назначения исполнителей, биллинг...
Одна из самых сложных задач тут — определиться с набором ограничений домена, который называется Bounded context. Про него в следующий раз.
https://medium.com/walmartglobaltech/building-domain-driven-microservices-af688aa1b1b8
https://habr.com/ru/post/428209/
https://martinfowler.com/bliki/BoundedContext.html
Стоит также посмотреть на каноничные труды по Domain Driven Design — книгу Эрика Эванса https://www.ozon.ru/context/detail/id/5497184/
#practices #ddd #microservices #en
Бывает, что появление нового микросервиса обязано техническими причинами, нежели обусловлено бизнесом. Например, микросервис делится на несколько, потому что в памяти перестают умещаться все кэши.
И хотя вроде бы целью разделения и было уменьшение связанности, но бизнес задачи как-то не ложатся и, например, структура Order живет в тысяче мест и везде значит что-то свое. Потом можно все это дело достаточно много рефакторить, чтобы привести в порядок.
Ключом для избегания таких проблем является подход к проектированию на основе предметной области. Суть его состоит в том, чтобы технические решения описывали бизнесовые сущности, так называемые домены (domains). Эти домены иерархичны — нижние домены описывают более высокоуровневые. Команды могут брать ответственность за домены с понятным скоупом ответственности.
Реализация функциональности затрагивает определенные домены, значит, понятно в кого идти и сколько делать.
Примеры доменов: заказ, клиент, исполнитель; счет, платеж, карта; пицца, курьер, пиццерия.
Примеры технических решения на основе доменов: система управления заказами, система назначения исполнителей, биллинг...
Одна из самых сложных задач тут — определиться с набором ограничений домена, который называется Bounded context. Про него в следующий раз.
https://medium.com/walmartglobaltech/building-domain-driven-microservices-af688aa1b1b8
https://habr.com/ru/post/428209/
https://martinfowler.com/bliki/BoundedContext.html
Стоит также посмотреть на каноничные труды по Domain Driven Design — книгу Эрика Эванса https://www.ozon.ru/context/detail/id/5497184/
#practices #ddd #microservices #en