UseCase это более вышележащий относительно агрегатов уровень приложения. Из UseCase вызывается функционал агрегатов. И скорее всего здесь можно обойтись одним агрегатом User. Приглашение достаточно быть в виде объекта-сущности, которая находится в виде ссылки в агрегате User. В таком случае получим - один агрегат - одна транзакция.
Странная тема обсуждения "DDD с/без ORM". DDD (логика домена) находится в logic layer. ORM используется в persistence layer. Логика домена, когда в неё приходят данные, полученные из бд, вообще не имеет никакого представления о том, что эти данные были получены при помощи ORM или какими-то другими механизмами.
Наверное это ключевой вопрос, который возникает при использовании DDD. Юз кейс работает с ключевым агрегатом, но при его обработке могут меняться и другие агрегаты. Следуя логике 1 агрегат = 1 транзакция в этом юз кейс в бд сохраняется только ключевой агрегат. По остальным агрегатам формируются доменные события с описаниям изменений агрегатов и эти события сохраняются таблицу событий Outbox. Здесь и возникает вопрос - кто будет просматривать эти данные в Outbox и вызывать юз кейсы для изменения каждого агрегата. Здесь логически продолжаю цепочку - у каждого юз кейс только один агрегат изменяется в транзакции. Значит для изменения каждого агрегата должен быть отдельный юз кейс. Если архитектура микросервисная у которой 1 микросервис=1 агрегат, то можно дёргать нужный микросервис для каждого изменённого агрегата. А если архитектура монолитная - то как?
Но если Вы хотите помещать валидаторы во вью или вьюмодель — дело Ваше. Вы просто не сможете переиспользовать валидаторы, если нужно будет вашу логику перенести на другую платформу. Всего лишь. придется их все написать по новой для каждой новой платформы.
Но далее пишите
вьюмодель1 для формы1 создает валидатор и настраивает его на диапазон 0..100. байндер1 связывает форму1 с только что созданным и настроенным на диапазон 0..100 валидатором.
Получается вначале валидатор во вьюмодель это плохо, а потом это хорошо?
Допустим валидаторы реализованы в доменной модели. Какие это может вызвать проблемы. Приведу простейший пример. В объекте доменной модели требует валидации поле А числового типа. С этим доменным объектом через цепочку вызовов между слоями работают форма1 и форма2 слоя presentation layer. Бизнес-правила приложения такие - с формы1 в поле А доменного объекта можно передавать значения в интервале 0...100, с формы2 в поле А доменного объекта можно передавать значения в интервале 10...50. Если использовать валидаторы на форме, то их легко настроить на валидацию в разных интервалах. Если валидаторы в домене, который вообще не знает про существование форм, каким образом сказать доменному валидатору, что в этом случае допустимы 0...100, а в другом случае 10...50? Нужны какие-то дополнительные признаки при передаче данных с формы в домен.
Кроме того существует множество приложений, в которых вообще нет домена и данные гоняются между визуальным интерфейсом и базой данных. Данные с визуальной формы сразу идут в persistence layer и далее в базу данных. Теоретически можно сделать валидаторы в dao объектах слоя persistence layer, но такого варианта никогда ещё не видел. В таких приложениях валидаторы находятся в логике слоя presentation layer.
Насчёт логики. Конечно View содержит определённую логику. Например перевести чекбокс из одного состояния в другое или поменять надпись на форме в зависимости от выбранного в комбобоксе значения. Для этого ViewModel не нужен. Но есть логика используемая глобально во всём слое presentation layer. Самый типовой пример такой логики - валидаторы данных, вводимых на визуальной форме. Например при вводе в текстовое поле должен быть формат данных типа email. Или валидатор сразу отслеживающий данные в двух полях дат - чтобы дата в одном поле всегда была больше даты в другом поле на форме. Валидатор может использоваться в любой визуальной форме приложения. Такой функционал будет во ViewModel.
Что касается термина "фасад", то это не в значении шаблона Банды Четырех. Наверное зря я его использовал. Под фасадом здесь понимается тот функционал, который обращён непосредственно к внешнему пользователю. В данном случае это View.
Presentation model - это модель данных всего слоя. Используется и во View и во ViewModel.
Немного конкретизирую своё виденье логической структуры шаблона MVVM.
View - это визуальный интерфейс приложения, который является фасадом слоя presentation layer и через который приложение взаимодействует с внешним пользователем.
View Model - реализует модель данных (presentation model) слоя presentation layer и внутреннюю логику слоя presentation layer.
Binder реализует двустороннее связывание данных между View и presentation model.
Model - это уже модель данных нижележащего слоя logic layer.
View Model содержит функционал (обычно он называется маппером), который наполняет Model используя данные из presentation model или наполняет presentation model используя данные из Model.
Прошу автора статьи и авторов комментариев поделиться, как они видят логическую структуру шаблона MVVM.
Не совсем понятен смысл использования динамических объектов. Давно использую самописный ORM и все операции типа DataTable -> Entity прекрасно выполняются при помощи рефлексии. Даже не представляю, где здесь можно использовать динамические объекты.
Для менее квалифицированного русского коммюнити такие подходы, пожалуй, сложноваты.
У меня несколько другое впечатление. Для русскоязычного коммюнити свойственна большая простота и ясность мышления в вопросах архитектуры. В первую очередь это касается публикаций на хабре. У многих главных западных авторов какая-то сложность и перекрученность. Особенно это касается книжек по ddd. Исключение это книги Мартина Фаулера. Все его книги просто замечательные.
Разделение на слои выглядит достаточно странно. Из приведенного в статье кода логично разделить на слои таким образом Controller, Application, Domain, Repository.
UseCase это более вышележащий относительно агрегатов уровень приложения. Из UseCase вызывается функционал агрегатов. И скорее всего здесь можно обойтись одним агрегатом User. Приглашение достаточно быть в виде объекта-сущности, которая находится в виде ссылки в агрегате User. В таком случае получим - один агрегат - одна транзакция.
С разными агрегатами работает или юз кейс или доменный сервис.
Странная тема обсуждения "DDD с/без ORM". DDD (логика домена) находится в logic layer. ORM используется в persistence layer. Логика домена, когда в неё приходят данные, полученные из бд, вообще не имеет никакого представления о том, что эти данные были получены при помощи ORM или какими-то другими механизмами.
А если агрегаты находятся в разных бд?
Наверное это ключевой вопрос, который возникает при использовании DDD. Юз кейс работает с ключевым агрегатом, но при его обработке могут меняться и другие агрегаты. Следуя логике 1 агрегат = 1 транзакция в этом юз кейс в бд сохраняется только ключевой агрегат. По остальным агрегатам формируются доменные события с описаниям изменений агрегатов и эти события сохраняются таблицу событий Outbox. Здесь и возникает вопрос - кто будет просматривать эти данные в Outbox и вызывать юз кейсы для изменения каждого агрегата. Здесь логически продолжаю цепочку - у каждого юз кейс только один агрегат изменяется в транзакции. Значит для изменения каждого агрегата должен быть отдельный юз кейс. Если архитектура микросервисная у которой 1 микросервис=1 агрегат, то можно дёргать нужный микросервис для каждого изменённого агрегата. А если архитектура монолитная - то как?
Яхты владельцев банков.
Вначале Вы пишите
Но далее пишите
Получается вначале валидатор во вьюмодель это плохо, а потом это хорошо?
Допустим валидаторы реализованы в доменной модели. Какие это может вызвать проблемы. Приведу простейший пример. В объекте доменной модели требует валидации поле А числового типа. С этим доменным объектом через цепочку вызовов между слоями работают форма1 и форма2 слоя presentation layer. Бизнес-правила приложения такие - с формы1 в поле А доменного объекта можно передавать значения в интервале 0...100, с формы2 в поле А доменного объекта можно передавать значения в интервале 10...50. Если использовать валидаторы на форме, то их легко настроить на валидацию в разных интервалах. Если валидаторы в домене, который вообще не знает про существование форм, каким образом сказать доменному валидатору, что в этом случае допустимы 0...100, а в другом случае 10...50? Нужны какие-то дополнительные признаки при передаче данных с формы в домен.
Кроме того существует множество приложений, в которых вообще нет домена и данные гоняются между визуальным интерфейсом и базой данных. Данные с визуальной формы сразу идут в persistence layer и далее в базу данных. Теоретически можно сделать валидаторы в dao объектах слоя persistence layer, но такого варианта никогда ещё не видел. В таких приложениях валидаторы находятся в логике слоя presentation layer.
Если валидируются данные на визуальной форме, тот как же такая валидация будет доменной.
Насчёт логики. Конечно View содержит определённую логику. Например перевести чекбокс из одного состояния в другое или поменять надпись на форме в зависимости от выбранного в комбобоксе значения. Для этого ViewModel не нужен. Но есть логика используемая глобально во всём слое presentation layer. Самый типовой пример такой логики - валидаторы данных, вводимых на визуальной форме. Например при вводе в текстовое поле должен быть формат данных типа email. Или валидатор сразу отслеживающий данные в двух полях дат - чтобы дата в одном поле всегда была больше даты в другом поле на форме. Валидатор может использоваться в любой визуальной форме приложения. Такой функционал будет во ViewModel.
Что касается термина "фасад", то это не в значении шаблона Банды Четырех. Наверное зря я его использовал. Под фасадом здесь понимается тот функционал, который обращён непосредственно к внешнему пользователю. В данном случае это View.
Presentation model - это модель данных всего слоя. Используется и во View и во ViewModel.
Немного конкретизирую своё виденье логической структуры шаблона MVVM.
View - это визуальный интерфейс приложения, который является фасадом слоя presentation layer и через который приложение взаимодействует с внешним пользователем.
View Model - реализует модель данных (presentation model) слоя presentation layer и внутреннюю логику слоя presentation layer.
Binder реализует двустороннее связывание данных между View и presentation model.
Model - это уже модель данных нижележащего слоя logic layer.
View Model содержит функционал (обычно он называется маппером), который наполняет Model используя данные из presentation model или наполняет presentation model используя данные из Model.
Прошу автора статьи и авторов комментариев поделиться, как они видят логическую структуру шаблона MVVM.
У даппера есть вариант при котором данные из запроса напрямую вносятся в объект Entity. Почему это не используете?
Не совсем понятен смысл использования динамических объектов. Давно использую самописный ORM и все операции типа DataTable -> Entity прекрасно выполняются при помощи рефлексии. Даже не представляю, где здесь можно использовать динамические объекты.
То что мне показалось интересным было или в книгах или на хабре. На хабре в том числе переводы западных авторов.
У меня несколько другое впечатление. Для русскоязычного коммюнити свойственна большая простота и ясность мышления в вопросах архитектуры. В первую очередь это касается публикаций на хабре. У многих главных западных авторов какая-то сложность и перекрученность. Особенно это касается книжек по ddd. Исключение это книги Мартина Фаулера. Все его книги просто замечательные.
Можете подсказать ссылки на подобные публикации или это сокрыто внутри проектов и не выносится наружу?
Представляется совершенно логично, что domain содержит 2 раздела - Entities и Logic. Совершенно непонятно зачем его разбивать на 2 модуля.
Разделение на слои выглядит достаточно странно. Из приведенного в статье кода логично разделить на слои таким образом Controller, Application, Domain, Repository.
В качестве Engine логично использовать корень агрегата. Как отдельный объект это будет чрезмерное усложнение кода. Сама идея достаточно интересная.
Если какой-то из коэффициентов представляет собой нелинейную функцию, то задача переходит на совершенно другой уровень сложности.