Мой вопрос немного о другом - в какой бизнес-логике событиями будут обмениваться агрегаты, а не объекты ViewModels? Про ViewModels всё понятно. Очень часто используется обмен событиями/сообщениями для изменения данных в ViewModels.
В литературе по DDD очень часто говорят об обмене событиями именно между агрегатами.
Возник вопрос по обмену доменными событиями между агрегатами внутри приложения без использования специального хранилища событий.
Почему возник этот вопрос. Рассмотрим приложение с визуальным интерфейсом. На форме располагаются несколько панелей с данными. В каждой панели отображаются данные отдельного агрегата. То есть на форме представлены данные нескольких агрегатов.
Но с панелью связан не сам агрегат, а объект view model, который наполняется данными из агрегата. И как раз раз не агрегаты, а объекты view model могут участвовать в обмене событиями, если в одной из панелей происходит изменение данных. Эта панель отправляет события другим панелям и их объекты view model будут меняться.
Не могу представить себе функционал в котором агрегаты взаимодействуют между собой при помощи событий внутри приложения. Может кто-то сталкивался с подобным функционалом?
Люди читают курс Enterprise Architect - то есть являются гуру в этой сфере и в тоже время дают такую информацию - "В CQRS отказываются от ORM (Object-Relational Mapping) в пользу использования агрегатов (Aggregates)". Это выглядит странно.
Не могу дать оценку либе, так как работаю с c# технологиями. Но если дать правильное архитектурное решение для этой задачи, то оно будет работать единообразно в разных технологиях и разных языках разработки.
Решал аналогичную задачу в проекте на технологии asp.net. Валидаторы входят в функционал presentation layer и логично, что валидаторы должны быть вписаны в общую архитектуру приложения. Внедряя в валидаторы EntityManager мы напрямую подключаем их к ORM - то есть выносим валидаторы за скобки используемой в приложении архитектуры. Поэтому логично из валидатора обращаться к слою persistence layer приложения, который работает с базами данных. А уже этот слой может использовать ORM или прямые запросы к бд. В этом случае от валидатора будут скрыты механизмы взаимодействия с бд.
>>persistenceContext - это очень сильно прокаченный кэш
Почему сразу не сказать, что это репозиторий данных, полученных из бд и данные из которого могут далее синхронизироваться с бд? Кэш это, на мой взгляд, достаточно размытое понятие.
Со времён появления работ Колмогорова начала 1940х годов понятно, что турбулентность - это чисто макроскопические явление. И моделировать его надо используя методологию и математический аппарат механики сплошной среды. Исходя из этого сложно понять какой результат можно получить путём "моделирования поведения отдельных атомов и молекул, численно решая их уравнения движения".
Кроме проверки уникальности по базе данных валидатор также проверяет соответствует ли написание email формату, принятому для почтовых адресов. Возможно дополнительные ограничения - например почтовый домен только из ограниченного набора доменов и т.д.
Очень хорошо сказано в комментарии https://habr.com/ru/articles/797425/#comment_26597341 - "ответственность репозитория должна быть ограничена сохранением и получением данных из хранилища, проверка бизнес-правил это ответственность слоя домена."
1) валидатор проверяет уникальность email по таблице базы данных; если email не уникален - генерируется ошибка;
2) если два пользователя одновременно создают записи с одинаковым email и валидация у них проходит правильно, то уже при сохранении в бд первый по времени сохранения пользователь завершает операцию сохранения данных в бд, а тот кто завершает транзакцию следующим по времени получает ошибку, которую генерирует индекс, следящий за уникальностью значения email в поле таблицы бд.
Конечно надо сделать уникальный индекс по полю с email в таблице базы данных. Но это не значит что не надо валидировать со стороны приложения. Валидация бизнес-данных - это элемент бизнес-логики приложения.
3 слоя / 3 подслоя это общий подход для построения архитектуры. Конечно в задаче сохранения пользователя в бд с валидацией его email не надо использовать всё теоретически возможные слои и подслои. Например калькулятору (такому как в винде) достаточно одного слоя состоящего из двух подслоёв.
Валидатор или набор валидаторов - это отдельный функциональный блок, который можно многократно использовать внутри logic layer. В этом отличие от варианта 3.
Мой вопрос немного о другом - в какой бизнес-логике событиями будут обмениваться агрегаты, а не объекты ViewModels? Про ViewModels всё понятно. Очень часто используется обмен событиями/сообщениями для изменения данных в ViewModels.
В литературе по DDD очень часто говорят об обмене событиями именно между агрегатами.
Возник вопрос по обмену доменными событиями между агрегатами внутри приложения без использования специального хранилища событий.
Почему возник этот вопрос. Рассмотрим приложение с визуальным интерфейсом. На форме располагаются несколько панелей с данными. В каждой панели отображаются данные отдельного агрегата. То есть на форме представлены данные нескольких агрегатов.
Но с панелью связан не сам агрегат, а объект view model, который наполняется данными из агрегата. И как раз раз не агрегаты, а объекты view model могут участвовать в обмене событиями, если в одной из панелей происходит изменение данных. Эта панель отправляет события другим панелям и их объекты view model будут меняться.
Не могу представить себе функционал в котором агрегаты взаимодействуют между собой при помощи событий внутри приложения. Может кто-то сталкивался с подобным функционалом?
Люди читают курс Enterprise Architect - то есть являются гуру в этой сфере и в тоже время дают такую информацию - "В CQRS отказываются от ORM (Object-Relational Mapping) в пользу использования агрегатов (Aggregates)". Это выглядит странно.
Не могу дать оценку либе, так как работаю с c# технологиями. Но если дать правильное архитектурное решение для этой задачи, то оно будет работать единообразно в разных технологиях и разных языках разработки.
Решал аналогичную задачу в проекте на технологии asp.net.
Валидаторы входят в функционал presentation layer и логично, что валидаторы должны быть вписаны в общую архитектуру приложения. Внедряя в валидаторы EntityManager мы напрямую подключаем их к ORM - то есть выносим валидаторы за скобки используемой в приложении архитектуры.
Поэтому логично из валидатора обращаться к слою persistence layer приложения, который работает с базами данных. А уже этот слой может использовать ORM или прямые запросы к бд. В этом случае от валидатора будут скрыты механизмы взаимодействия с бд.
>>persistenceContext - это очень сильно прокаченный кэш
Почему сразу не сказать, что это репозиторий данных, полученных из бд и данные из которого могут далее синхронизироваться с бд? Кэш это, на мой взгляд, достаточно размытое понятие.
Как показала многолетняя практика на определённом уровне сложности запросов - ORM выбрасывается и проект переделывается на прямые sql запросы.
Use case / application service являются фасадом слоя logic layer. Управление транзакциями тоже здесь находится. Фаулер это называет application logic.
Очень часть под use case как раз и понимают application service
Со времён появления работ Колмогорова начала 1940х годов понятно, что турбулентность - это чисто макроскопические явление. И моделировать его надо используя методологию и математический аппарат механики сплошной среды. Исходя из этого сложно понять какой результат можно получить путём "моделирования поведения отдельных атомов и молекул, численно решая их уравнения движения".
Кроме проверки уникальности по базе данных валидатор также проверяет соответствует ли написание email формату, принятому для почтовых адресов. Возможно дополнительные ограничения - например почтовый домен только из ограниченного набора доменов и т.д.
Оплата заказа в объекте "Оплата"
Очень хорошо сказано в комментарии https://habr.com/ru/articles/797425/#comment_26597341 - "ответственность репозитория должна быть ограничена сохранением и получением данных из хранилища, проверка бизнес-правил это ответственность слоя домена."
Ошибка конечно одна и та же. Мой подход такой:
1) валидатор проверяет уникальность email по таблице базы данных; если email не уникален - генерируется ошибка;
2) если два пользователя одновременно создают записи с одинаковым email и валидация у них проходит правильно, то уже при сохранении в бд первый по времени сохранения пользователь завершает операцию сохранения данных в бд, а тот кто завершает транзакцию следующим по времени получает ошибку, которую генерирует индекс, следящий за уникальностью значения email в поле таблицы бд.
Конечно надо сделать уникальный индекс по полю с email в таблице базы данных. Но это не значит что не надо валидировать со стороны приложения. Валидация бизнес-данных - это элемент бизнес-логики приложения.
3 слоя / 3 подслоя это общий подход для построения архитектуры. Конечно в задаче сохранения пользователя в бд с валидацией его email не надо использовать всё теоретически возможные слои и подслои. Например калькулятору (такому как в винде) достаточно одного слоя состоящего из двух подслоёв.
Валидатор или набор валидаторов - это отдельный функциональный блок, который можно многократно использовать внутри logic layer. В этом отличие от варианта 3.
Валидатора как такового нет. Напрямую идёт обращение к репозиторию
usersRepository.GetByEmail(email)На мой взгляд валидатор надо выделить в отдельный объект и далее его можно многократно использовать внутри logic layer.
Императив очень простой - задача валидации, которая рассматривается в статье, решается внутри слоя logic layer.
Пусть это будет не статья, а вариант 6 для статьи https://habr.com/ru/articles/797425/