Насчёт логики. Конечно 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.
Репозитории я вообще не включаю в доменный слой, т.к. считаю что даже доменные сервисы не должны иметь зависимостей (хоть DDD это и не запрещает), чтобы не смешивать бизнес и инфра-логику.
Наконец-то в первый раз встречаю мнение сходное с моим. Начиная с первых книг по ддд репозитории постоянно упоминаются в составе функционала, связанного с доменом. Но это же совсем разные вещи. С доменом связаны доменная логика и модель данных домена. Репозитории работают с персистентными данными и персистентной моделью данных. И как раз книги по ддд говорят о необходимости разделения функционала домена и функционала работающего с базами данных.
Не позволять разным агрегатам напрямую ссылаться друг на друга, только по id.
В моём понимании агрегаты вообще не должны знать о существовании друг друга даже если это вызов другого агрегата по его id. Если необходимо работать с несколькими агрегатами, то это делает или доменный сервис или use case из которого идёт вызов логики домена.
InfoQ странный ресурс. Из всего что они публиковали по архитектуре только одна статья мне показалась ценной и информативной. В остальных контент странного содержания - не вижу как его применить в практических задачах. А архитектура это как раз про применимость на практике.
Неужели хранение в одной папке событий TemplateChanged.php, TemplateArchivated.php и репозитория TemplateRepositoryInterface.php - это и есть результат многолетнего осмысления ддд?
Если валидируются данные на визуальной форме, тот как же такая валидация будет доменной.
Насчёт логики. Конечно 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 логично использовать корень агрегата. Как отдельный объект это будет чрезмерное усложнение кода. Сама идея достаточно интересная.
Если какой-то из коэффициентов представляет собой нелинейную функцию, то задача переходит на совершенно другой уровень сложности.
В C# double не даёт нужной точности значения. Всегда использую decimal.
Наконец-то в первый раз встречаю мнение сходное с моим. Начиная с первых книг по ддд репозитории постоянно упоминаются в составе функционала, связанного с доменом. Но это же совсем разные вещи. С доменом связаны доменная логика и модель данных домена. Репозитории работают с персистентными данными и персистентной моделью данных. И как раз книги по ддд говорят о необходимости разделения функционала домена и функционала работающего с базами данных.
В моём понимании агрегаты вообще не должны знать о существовании друг друга даже если это вызов другого агрегата по его id. Если необходимо работать с несколькими агрегатами, то это делает или доменный сервис или use case из которого идёт вызов логики домена.
То есть предполагается, что доменный сервис всегда находится в папке определённого агрегата даже когда работает с несколькими агрегатами?
Куда поместить доменный сервис, который работает сразу с двумя агрегатами?
InfoQ странный ресурс. Из всего что они публиковали по архитектуре только одна статья мне показалась ценной и информативной. В остальных контент странного содержания - не вижу как его применить в практических задачах. А архитектура это как раз про применимость на практике.
Каждый день смотрю на на модули/неймспейсы. Но хранить вместе события и репозитории никогда не буду. Но это конечно дело вкуса.
Неужели хранение в одной папке событий TemplateChanged.php, TemplateArchivated.php и репозитория TemplateRepositoryInterface.php - это и есть результат многолетнего осмысления ддд?
Наверху командуют такие люди, что всегда повернут стрелочку куда надо.