Там в основе взяты akkatecture.net и EventFlow (с которого «слизана» akkatecture.net). Нам удалось существенно развить функционал в том числе в части саг и доменных сервисов, уйти от чистого EventSourcing и много еще интересного. Но проект, к сожалению, ушел из opensource.
Позволю себе не согласится.
Простота развёртывания и обновления любого из микросервисов нивелируется ростом взаимных зависимостей между сервисами, которые необходимо учитывать по мере роста их количества. Что и усложняет задачи DevOps.
В новой версии все что журналируется через ILogger будет доступно на вкладке «Log» у каждой ошибки. Там будут только записи, которые относятся к HTTP сессии в которой произошла ошибка.
Про Interceptor — интересна идея, попробую добавить в следующей версии
Связей будет столько — сколько есть в вашем бизнес домене. Для упрощения реализации используйте разбиение домена на изолированные контексты (в каждом из них будет своя девочка со связями нужными только в этом конексте, а значит их будет меньше). А вы для упрощения решения задачи предлагаете не разбивать домен на изолированные контексты, а создавать кучу разных сервисов в одном контексте. Это не DDD!
Не заменяйте сущности предметной области сервисами для упрощения разработки — это «коверкает» единый язык контекста и противоречит самой концепции DDD, где мы пытаемся моделировать предметную область на одном языке между программистами и экспертами.
В таком случае вы не до конца понимаете концепции DDD: единый язык, изолированные контексты, сущности и агрегаты — это части предметной области (домена), которые должны отражать моделируемые объекты из реального мира и одинаково трактоваться и бизнес экспертами и аналитиками и разработчиками ("девочка" — это сущность, а не сервис) и находить соответствующее отражение в коде.
А вы все сводите только сервисам и "голым" моделям. Это точно не DDD и не ООП, а возврат к процедурному программирование.
Посмотрите как Верон моделирует домен с помощью Event Storming. Он выделяет события, агрегаты и команды. Агрегаты исполняют команды (реализуют поведение), "выбрасывая" события. Сервисы вторичны в этой истории, и используются для моделирования процессов над агрегатами (бизнес логики вне агрегатов).
В вашем примере как минимум три сущности: девочка, пульт и телевизор. Именно девочка выполняет действие «включить телевизор», в рамках которого она понимает, что не может достать до кнопки (зная свой рост), она «ищет пульт» (еще одно действие девочки), и нажимает на нем кнопку. Пульт посылает сигнал телевизору. Телевизор включается, в ответ на сигнал пульта. Все операции — это поведение сущностей, а не сервисов.
Согласно концепции DDD отделять доменную логику от агрегата в сервис (Domain Service) нужно в том случае, если ее нельзя отнести к какой-то конкретной сущности или объекту-значению.
Операция не принадлежит ни одному из объектов предметной области
Операция выполняется над различными объектами предметной области
Злоупотребление приводит к «анемичной модели предметной области», как я говори ранее. Так что оставьте возможность реализации доменной логики в агрегате, если не хотите расстраивать Мартина и Эрика :)
dddsample-core — это реализация на Java примеров, о которых говорит Эрик Эванс в своей книге. Они хорошо прокомментированы, так что будет легко разобраться.
Вот например реализация сущности Cargo содержит как данные (TrackingId, origin, delivery), причем доступ к ним защищен согласно принципу инкапсуляция ООП, таки поведение (specifyNewRoute, assignToRoute,...)
Ко всему надо подходить рационально и не уходить в крайности.
и
класс Сущность не имеет никаких методов собственного изменения
не совместимы. Согласно ООП и DDD, сущности точно могут менять собственное состояние. А вы им это не даете делать в принципе — это точно ошибка.
Вы пытаетесь подменить понятие «Сущность/Агрегат» на понятие «Состояние сущности/агрегата». Сущность — это данные и поведение.
Что, в соответствии с мыслями Алана Кэя, является самым главным в ООП? — … Динамическая привязка (т.е. Позднее связывание)…
Что в ООП несущественно? — … Полиморфизм…
Но, Полиморфизм — это не что иное как реализация позднего связывания!
Да
Простота развёртывания и обновления любого из микросервисов нивелируется ростом взаимных зависимостей между сервисами, которые необходимо учитывать по мере роста их количества. Что и усложняет задачи DevOps.
Про Interceptor — интересна идея, попробую добавить в следующей версии
Не заменяйте сущности предметной области сервисами для упрощения разработки — это «коверкает» единый язык контекста и противоречит самой концепции DDD, где мы пытаемся моделировать предметную область на одном языке между программистами и экспертами.
В таком случае вы не до конца понимаете концепции DDD: единый язык, изолированные контексты, сущности и агрегаты — это части предметной области (домена), которые должны отражать моделируемые объекты из реального мира и одинаково трактоваться и бизнес экспертами и аналитиками и разработчиками ("девочка" — это сущность, а не сервис) и находить соответствующее отражение в коде.
А вы все сводите только сервисам и "голым" моделям. Это точно не DDD и не ООП, а возврат к процедурному программирование.
Посмотрите как Верон моделирует домен с помощью Event Storming. Он выделяет события, агрегаты и команды. Агрегаты исполняют команды (реализуют поведение), "выбрасывая" события. Сервисы вторичны в этой истории, и используются для моделирования процессов над агрегатами (бизнес логики вне агрегатов).
Согласно концепции DDD отделять доменную логику от агрегата в сервис (Domain Service) нужно в том случае, если ее нельзя отнести к какой-то конкретной сущности или объекту-значению.
Злоупотребление приводит к «анемичной модели предметной области», как я говори ранее. Так что оставьте возможность реализации доменной логики в агрегате, если не хотите расстраивать Мартина и Эрика :)
dddsample-core — это реализация на Java примеров, о которых говорит Эрик Эванс в своей книге. Они хорошо прокомментированы, так что будет легко разобраться.
Вот например реализация сущности Cargo содержит как данные (TrackingId, origin, delivery), причем доступ к ним защищен согласно принципу инкапсуляция ООП, таки поведение (specifyNewRoute, assignToRoute,...)
Вы пытаетесь подменить понятие «Сущность/Агрегат» на понятие «Состояние сущности/агрегата». Сущность — это данные и поведение.
После последнего абзаца, как-то сильно "запахло" анемичными моделями.
Но, Полиморфизм — это не что иное как реализация позднего связывания!