Всем привет!

Короткий пост про DDD. На мой взгляд это полезная технология, имеет смысл ее изучить. Но есть важный момент. Доменный слой это в первую очередь доменная логика. Доменные объекты нужны для использования в доменной логике, DTO и @Entity там быть не должно. Но есть куча приложений, где нет доменной логики, или она минимальная. Например, в middleware слое. Или реально микро микросервис) А доменный слой - это в нагрузку mapper-ы из/в DTO.

Поэтому вывод: не надо создавать доменный слой и использовать DDD везде и всегда. Во главу угла ставим целесообразность.

#ddd

Всем привет!

Этим постом завершается серия по паттерну Сага.

В предыдущем посте забыл упомянуть 3-й и 4-й способ реализации Саги.

Третий - если вы используете BPMN движок, например, Camunda, то он отлично подходит для оркестратора Саги. Более того, использовать BPMN как оркестратор - лучшая идея, чем использовать его как среду для low-code разработки. Ну не верю я в low-code, не сталкивался с работающими кейсами) Главные плюсы BPMN в данном - случае готовая state machine и визуализация Саги. К слову сама Camunda поставила этот use case на первое место в списке https://camunda.com/solutions/microservices-orchestration/ что как бы намекает. На всякий случай: Camunda - это самый распространенный BPMN движок, собственно движок - opensource, платить нужно только за UI консоль.

Аналогично - если вы уже используете Apache Camel - он тоже умеет в сагу, https://camel.apache.org/components/4.4.x/eips/saga-eip.html

Тут встает вопрос - стоит ли внедрять данные инструменты только ради Саги? Базовый ответ нет, идеальный кейс: если какой-то из этих компонент уже у вас используется - логично реализовать оркестрацию с его помощью. Я бы внедрял, если бы были какие-то еще плюсы от использования, кроме собственно реализации паттерна.

Еще важный момент при реализации оркестратора - stateless или statefull? Да, любая бизнес операция имеет как минимум ID и состояние, которые нужно хранить. Но необязательно это делать в классе Саги. Особенно используя event driven подход, можно просто передавать все не необходимые данные в событиях\командах. Напомню, при этом сохранение состояния операции в БД - это тоже событие. Плюс такого подхода - не нужно думать о букве D из ACID, т.е. персистентности, для данных, хранимых в оркестраторе. А где персистентность, там и кэширование, т.к. обращение к БД - дорого. И восстановление данных из БД при сбоях. Поэтому если вы все же решили хранить состояние операции в коде - я бы рекомендовал не изобретать велосипед, а воспользоваться готовым фреймворком. Два из них я уже упомянул выше, но они достаточно "тяжелые". Вот еще несколько, заточенных собственно под паттерн Сага и под DDD, который в общем-то тесно связан с сагой. Ведь если мы делим систему на ограниченный контексты, Bounded Context, то их данные лежат в разных БД, а следовательно возникает распределенная транзакция...

1) Axios https://docs.axoniq.io/reference-guide/v/3.1/part-ii-domain-logic/sagas
2) Eventuate Tram Saga https://eventuate.io/docs/manual/eventuate-tram/latest/getting-started-eventuate-tram-sagas.html
3) Seata https://www.seata.io/docs/user/mode/saga


Фреймворк помогает нам с:
а) персистентностью
б) кэшированием
в) созданием экземпляра саги для конкретной бизнес-операции
г) удобной работой с параметрами операции

При этом он не отменяет написания кода оркестрации и компенсирующих действий.

На этом пожалуй все.
Хотя нет. Остается вопрос - как же лучше реализовать Сагу? Ответ - лучше сделать свой ограниченный контекст = микросервис таким, чтобы Сага была не нужна)
А если серьезно.
1) постарайтесь использовать только локальные транзакции
2) если это не возможно, и у вас 2-4 шага - используйте хореографию
3) если шагов от 4+ и сервис создаётся с нуля - используйте оркестратор, для начала самописный, stateless event driven
4) у вас уже используется Camunda или Camel - делайте оркестратор на их основе
5) если вас нужен state - используйте фреймворки из последнего списка, например, Axios
6) если нужна сага и state machine - Camunda или Seata

#saga #microservices #ddd #patterns

Всем привет!

Разработка ПО - очень динамичная сфера. Мэйнфреймы, ассемблер, CSV, RDBMS, C, Delphi, Java, REST, MQ, git, DevOps, Docker, k8s, Kafka, noSQL, microservices, reactive programming, DataLake, GitOps, ChatGPT...
Но есть вещи, которые не меняются. 1967 год, сформулирован закон Конвея - Любая организация, которая разрабатывает систему (в широком смысле), вынуждена создавать проекты, структуры которых являются копией структуры связей организации.
Причем если верить wiki, а в данном случае IMHO это можно делать, закон даже был доказан, видимо на исследовании реальных компаний.
Так вот, читаю сейчас одну интересную книгу про внедрение DDD - Domain Driven Development, 2022 года выпуска. В главе про внедрение вижу такой совет - начать с того, что определить бизнесовые поддомены в компании, на основании которых будут строится ограниченные контексты - одна из ключевых сущностей DDD. Как их проще всего определить? Рекомендуется посмотреть на структуру организации. Закон Конвея в DDD)

P.S. Интересно и то, что в 1967 году разработка как отрасль уже достигла уровня, позволяющего формулировать определенные принципы.

#ddd #dev_law #book_review

Всем привет!

Попробую немного развить тему с законом Конвея из предыдущего поста.
Я достаточно много раз за свою карьеру в разработке сталкивался с упоминанием данного закона. Уже не вспомню где конкретно, но у меня осталось стойкое впечатление, что отношение к нему было как к неизбежности, с которой нужно бороться. Способы борьбы можно вспомнить такие:
1) корпоративные архитекторы, выравнивающие архитектурные шаблоны
2) внутренние платформы, обязательные к использованию внутри компании и реализующие единообразно нефункциональные требования
3) техрадар как способ ограничить технологический стек
4) единые практики найма и онбординга
5) корпоративная модель данных - как антипод принципа DDD, когда существует некая общая для организации единственно верная доменная модель
...

Так вот - что мне нравится в парадигме DDD, что она говорит - не надо бороться, надо принять как данность, расслабиться и получать удовольствие от своего ограниченного контекста) Ремарка – речь про применение закона в проектировании ПО.

#ddd #dev_law

Всем привет!

Поговорим снова о микросервисах. Я уже писал, почему не стоит делать слишком мелкие микросервисы https://t.me/javaKotlinDevOps/305
Но встает закономерный вопрос - "сколько вешать в граммах", в смысле - а какого размера должны быть микросервисы?
Обозначим нижний и верхний предел, а для этого придется вспомнить DDD.

Для начала рассмотрим понятие ограниченного контекста (bounded context). Это связанный набор сущностей из реального мира, для наименования которых используется "единый язык" (ubiquitous language) - непротиворечивый набор терминов. Эти сущности описываются в аналитике, тест-кейсах и превращаются в классы в нашем сервисе и в таблицы в БД. Контекстом как правило занимается одна команда - так проще всего поддерживать "единый язык". И за микросервис тоже должна отвечать одна команда. Т.е. ограниченный контекст - это отличный кандидат на микросервис. Но при этом у одной команды может быть несколько микросервисов. И контекст может быть достаточно большим. Т.е. у нас есть верхняя граница микросервиса.

Теперь рассмотрим понятие агрегата - группу сущностей, имеющую уникальный идентификатор, изменение которой производится атомарно. Т.е. агрегат - граница транзакции в БД. А т.к. возможность делегировать управление транзакцией СУБД - это очень крутая штука, то разделять агрегат между разными БД не стоит. При этом один микросервис = одна БД. Поэтому агрегат - нижняя граница микросервиса.

#microservices #ddd

Всем привет!

Вопрос - где применяется подход DDD?
Аналитика, разработка, тестирование. Конечно архитектура АС, с нее все начинается.
Но это еще не все.
Есть такой класс систем как Data Warehouse (DWH) или аналитическое хранилище данных. В это хранилище попадают данные из всех бизнес-сервисов компании для дальнейшего анализа. Т.об. мы разделяем оперативную БД и аналитическую, снимая лишнюю нагрузку с оперативной БД. Особенность Data Warehouse - технологии обработки и хранения данных отличаются от используемых в системах оперативной обработки данных. Hadoop, Greenplum, ClickHouse... А значит нужны специалисты, которые подготовят хранилище под ваши данные и настроят синхронизацию с оперативной БД. Но эти специалисты не знают ваш домен, в отличие от команды. Плюс они часто становятся "бутылочным горлышком". Плюс структура данных постоянно меняется...
Что делать?
Data Warehouse специалисты готовят инфраструктуру, а за подготовку и синхронизацию данных, актуальность их структуры и способ предоставления этих данных потребителям отвечает бизнес команда. Это же ее bounded context. Подход называется Data Mesh. Вот неплохая статья на эту тему https://habr.com/ru/companies/vk/articles/720652/
P.S. На самом деле DevOps в своем идеальном виде о том же - DevOps инженеры готовят инфраструктуру, а за сборку и деплой отвечает команда.

#ddd #data_mesh

Всем привет!

Cуммирую серию постов про DDD - https://telegra.ph/Izuchaem-DDD--predmetno-orientirovannoe-proektirovanie-08-30

#ddd #books #book_review