- потребителями одних и тех же данных могут быть несколько разных бизнес-логик;
Это вопрос многослойности приложения. Данные из бд извлекаются при помощи persistence layer, который могут использовать разные микросервисы. А доменная логика у каждого микросервиса своя.
Мне интересна сама логика работы консюмера в вашем примере. Чтобы выполнить один use case консюмер вначале обращается к микросервису, который извлекает данные из бд, а потом полученные данные консюмер передаёт в другой микросервис, который реализует доменную логику этого use case? Правильно понимаю?
2. Отделение бизнес‑логики от данных и состояния. Это принцип из классического программирования. Если сервис является мастер‑системой, то он отвечает за хранение данных, их обновление и предоставление доступа к чтению. Не нужно в тот же сервис вмещать бизнес‑логику, лучше её вынести в отдельный микросервис.
То есть предлагается извлекать данные из бд одним микросервисом, а потом полученные данные передавать другому микросервису, который реализует бизнес-логику?
Но микросервис - это же в общем случае полнофункциональное приложение и при необходимости вполне логично, что он извлекает данные из бд, потом применяет к ним алгоритмы бизнес-логики и результат отдаёт консюмеру, который сделал запрос. Не совсем понятно зачем бизнес-логику вынести в отдельный микросервис.
Если в самый внешний слой, приведенного выше рисунка, не включать опцию DB, то это будет описание взаимодействия от внешнего консюмера до Entities. Для того чтобы получить полное описание архитектуры надо надавить ещё один рисунок внутренняя сфера которого это Entities, а внешняя сфера, которая окружает Entities, это DB (фреймворки и драйвера). Направление взаимодействия в виде стрелок идет от Entities к DB.
Но опять же не вижу каких-то преимуществ в таком виде представления перед стандартным вариантом многослойной архитектуры. Моя версия описания многослойной архитектуры здесь https://habr.com/ru/articles/667922/.
Также ещё одно отличие - на левом рисунке в голубом слое справа есть пункт DB (база данных), а в рисунке из книги нет такого пункта. В англоязычном варианте книги есть опция пункт DB в этом рисунке. Это очень странно - помещать визуальный интерфейс и базу данных в один слой. Визуальный интерфейс и функционал доступа к базе данных находятся в противоположных слоях приложения.
Возник вопрос - почему в иерархии наследования репозиториев появляется класс StorageBase<Entity>, хотя совершенно логично его назвать ARepository<Entity>. В чём причина такого названия для базового класса?
В одних приложениях данные курсируют между визуальным интерфейсом и базой данных. В других огромная бизнес-логика и сохранение результатов в бд это только совсем малая часть бизнес-логики приложения. И здесь как возможен кирпичик «postgresql adapter”.
Уже много лет читаю про гексогональную литературу и мне совершенно очевидно, что она совершенно легко и просто трансформируется в обычную многослойную архитектуру. Не могу понять зачем надо так упорно говорить отдельно о гексогональной и отдельно о многослойной архитектуре???
Если и бизнес-данные и события сохраняются в одной транзакции, то это идеальная ситуация. Но к сожалению в реальных бизнес-системах так не получается сделать - используются разные базы данных на разных серверах.
Оракл - продуктовая бд заказчика и к ней имеем доступ в рамках бизнес-логики системы. Добавление новых схем и таблиц в неё невозможно. Постгре - внутренняя бд нашей системы и с ней можно делать всё что угодно.
Если бизнес-данные и события хранятся в разных базах данных и их нельзя поместить в одну транзакцию - как в этом случае построить алгоритм публикации события?
Продолжение тематики, обсуждаемой в этой статье, смотрите в статье "Валидация данных на уровне бизнес-логики приложения".
Это вопрос многослойности приложения. Данные из бд извлекаются при помощи persistence layer, который могут использовать разные микросервисы. А доменная логика у каждого микросервиса своя.
Мне интересна сама логика работы консюмера в вашем примере. Чтобы выполнить один use case консюмер вначале обращается к микросервису, который извлекает данные из бд,
а потом полученные данные консюмер передаёт в другой микросервис, который реализует доменную логику этого use case? Правильно понимаю?
Вопрос по пункту
2. Отделение бизнес‑логики от данных и состояния. Это принцип из классического программирования. Если сервис является мастер‑системой, то он отвечает за хранение данных, их обновление и предоставление доступа к чтению. Не нужно в тот же сервис вмещать бизнес‑логику, лучше её вынести в отдельный микросервис.
То есть предлагается извлекать данные из бд одним микросервисом, а потом полученные данные передавать другому микросервису, который реализует бизнес-логику?
Но микросервис - это же в общем случае полнофункциональное приложение и при необходимости вполне логично, что он извлекает данные из бд, потом применяет к ним алгоритмы бизнес-логики и результат отдаёт консюмеру, который сделал запрос. Не совсем понятно зачем бизнес-логику вынести в отдельный микросервис.
Если в самый внешний слой, приведенного выше рисунка, не включать опцию DB, то это будет описание взаимодействия от внешнего консюмера до Entities. Для того чтобы получить полное описание архитектуры надо надавить ещё один рисунок внутренняя сфера которого это Entities, а внешняя сфера, которая окружает Entities, это DB (фреймворки и драйвера). Направление взаимодействия в виде стрелок идет от Entities к DB.
Но опять же не вижу каких-то преимуществ в таком виде представления перед стандартным вариантом многослойной архитектуры. Моя версия описания многослойной архитектуры здесь https://habr.com/ru/articles/667922/.
Также ещё одно отличие - на левом рисунке в голубом слое справа есть пункт DB (база данных), а в рисунке из книги нет такого пункта. В англоязычном варианте книги есть опция пункт DB в этом рисунке. Это очень странно - помещать визуальный интерфейс и базу данных в один слой. Визуальный интерфейс и функционал доступа к базе данных находятся в противоположных слоях приложения.
Получается что достижение состоит в том, что ракета не упала на стартовый стол, а смогла выйти на орбиту.
В чём состоит успех Луны-25 ?
Для интерфейса interface ReportsRepo в статье даётся описание метода
fun save(user: Report): Report
Предполагаю что должно быть
fun save(report: Report): Report
Очень интересная статья. Сильно выходит за рамки того, что обычно пишут в статьях и книгах по ddd.
Возник вопрос - почему в иерархии наследования репозиториев появляется класс StorageBase<Entity>, хотя совершенно логично его назвать ARepository<Entity>. В чём причина такого названия для базового класса?
У Мартина Фаулера книга прекрасная, но она не имеет отношения к ddd.
То есть нет такой сущности как контроллер? Под контроллером понимается взаимодействие handlers -> use case ?
Само приложение создаётся для реализации бизнес-логики. Остальные слои только помогают в выполнении задач бизнес-логики.
В одних приложениях данные курсируют между визуальным интерфейсом и базой данных. В других огромная бизнес-логика и сохранение результатов в бд это только совсем малая часть бизнес-логики приложения. И здесь как возможен кирпичик «postgresql adapter”.
Уже много лет читаю про гексогональную литературу и мне совершенно очевидно, что она совершенно легко и просто трансформируется в обычную многослойную архитектуру. Не могу понять зачем надо так упорно говорить отдельно о гексогональной и отдельно о многослойной архитектуре???
Для естественного упорядочения записей в таблицу вводится новая колонка CreatedDateTime это записи и индекс по этой колонке.
Если и бизнес-данные и события сохраняются в одной транзакции, то это идеальная ситуация. Но к сожалению в реальных бизнес-системах так не получается сделать - используются разные базы данных на разных серверах.
Оракл - продуктовая бд заказчика и к ней имеем доступ в рамках бизнес-логики системы. Добавление новых схем и таблиц в неё невозможно. Постгре - внутренняя бд нашей системы и с ней можно делать всё что угодно.
Абсолютно стандартная ситуация - продуктовая бд на оракле, а бд на которой можно реализовать Transactional outbox pattern на постгре.
Если бизнес-данные и события хранятся в разных базах данных и их нельзя поместить в одну транзакцию - как в этом случае построить алгоритм публикации события?