Похоже не совсем понимаю проблему у автора комментария. В одном DTO добавляю поля Tags, а в другом DTO нет таких полей, если они не нужны в функционале использующем DTO.
Если речь идёт о работе с транзакциями, то конечно надо знать условия вызова commit/rollback.
слой работы с Entity должен неявно знать структуру будущего DTO
Слой работающий с DTO более высоко лежащий, чем слой с Entity. И как раз слой с DTO знает всё про наличие и структуру Entity. И это вполне естественно, так как DTO наполняется данными из объектов Entity. А слой с Entity ничего не знает про слой с DTO. Такова логика многослойной архитектуры. Если ею не пользоваться, то ничего не могу сказать по этому вопросу.
Отличный комментарий - смешаны транзакции, Entity, LazyInitializationException и "слоеные архитектуры" как очередной marketing bullshit.
Но мне ответить очень легко.
DTO - это не обязательно какой-то аналог Entity. DTO может включать в себя информацию из разных Entity объектов и слой, содержащий DTO, конечно не имеет никакого отношения к тому как и где реализованы транзакции.
Что касается LazyInitializationException, то совершенно не обязательно, что Entity наполняется при помощи ORM фреймворка, который вызывает упомянутую исключительную ситуацию. Но даже при использовании ORM функционал слоя работающего с Entity должен быть реализован так, чтобы исключить возникновение LazyInitializationException.
Что касается транзакций, то типовой алгоритм следующий. Допустим работа с Entity идёт в logic layer. Функционал работающий с Entity помещается внутри функционала use case или по Фаулеру это application logic (это тоже logic layer). При старте метода в объекте application logic запускается транзакция, а затем отрабатывает нужный функционал с Entity. Если при работе метода не возникли exception, то по завершению функционала метода application logic отрабатывает commit транзакции, в противном случае rollback. Возникновение LazyInitializationException откатит транзакцию, а сообщение об этой ошибке покажет разработчику её источник.
Проблема настолько распространена, что породила в сообществе целые баталии на тему «где правильно делать маппинг Entity ↔ DTO».
Если использовать многослойную архитектуру, то ответ на этот вопрос очевиден. DTO находится в более высоко лежащем слое приложения, чем слой в котором находится Entity. Соответственно слой с Entity не знает, что существуют объекты DTO - слои связаны между собой однонаправленно. Поэтому маппинг Entity ↔ DTO происходит в слое в котором находятся объекты DTO.
То есть FSD сосредотачивается на том, чтобы изолировать друг от друга бизнес-функции. В то время, как в первую очередь нужно изолировать бизнес-логику от внешних факторов: источников данных и представления. Это залог управляемости, масштабируемости и тестируемости бизнес-логики.
Если FSD порождает столько проблем, которые описаны в статье и комментах, то возникает естественный вопрос, а зачем FSD вообще использовать. Берите многослойную архитектуру - она работает на всех масштабах от простейших приложений до огромных.
Или что "View" может быть не только куском готового HTML, но и JSON-моделькой?
Наверное будет правильно так описать различия:
1) для приложения с визуальным интерфейсом "View" это "View Template" в который помещены данные "View model" и такой контент web-сервер отдаёт для прорисовки в броузере;
2) для веб-сервиса JSON-модель это data transfer object.
Когда самолет разгоняется по взлетной полосе, вокруг крыла и фюзеляжа рождаются сложные вихри. Мы привыкли считать, что инженеры давно научились описывать эти потоки уравнениями, но у этих уравнений есть собственная загадка: уже больше ста лет математики спорят, могут ли в идеальной модели газа или жидкости ни с того ни с сего возникать "разрывы" — сингулярности, где скорости и градиенты формально устремляются к бесконечности. От ответа зависят и наше понимание турбулентности
В идеальной модели газа отсутствует диссипация энергии и сингулярность связана с математическими свойствами уравнений, описывающих такую модель. В реальной модели - уравнение Навье-Стокса - скорее всего нет таких сингулярностей и механизмы турбулентности возникают по совсем другой причине - в течении вихри крупного масштаба теряют устойчивость и распадаются на вихри более мелкого масштаба. Более того возможно уравнение Навье-Стокса в известном сейчас виде и не описывает турбулентность. И для описания турбулентности требует какой-то модификации. Это сейчас очень обсуждаемый вопрос.
Переписывать код под акцию - это полная дичь. Все изменения цен под акции должны быть на уровне данных в бд, а код системы знает как пересчитывать цену конкретному покупателю под конкретную акцию.
Если приложение содержит доменную логику, то такая связь должна быть. Если этой связи нет, то встречный вопрос - кто будет запускать алгоритмы доменной логики?
В указанной автором статьи книге авторов Гарри Персиваль, Боб Грегори в итоговой общей схеме архитектуры почему-то выпала связь между блоком обработчиков (handlers) и предметной областью (domain). Эта связь многократно указана в книге - например в рисунке 7.5. Но в итоговой схеме её нет. Если приложение содержит функционал домена (предметную область), то нельзя обойтись без связки handlers -> domain.
Каким образом принцип наименьшего действия Лагранжа связан с нейросетью? Там классическая механика (набор материальных точек с ненулевой массой) с набором законов сохранения. Как это переносится на нейросеть?
Меня давно интересовал случай, когда в саге упадёт откат одной из транзакций - тогда и "eventual consistency" не удастся достигнуть. Поэтому при работе например с деньгами никак нельзя уйти от two-phase commit или работать только с одной бд (но такое часто бывает невозможно).
Мне кажется наиболее логичным вложить функционал, реализованный в CrossDomainCoordinator, в юз кейс "Отменить заказ" в виде метода или вложенного объекта.
Потащим ли мы вызов из одного адаптера в другой через сервисный слой?
Из Вашего рисунка это как раз отлично видно, что запрос из входного адаптера всегда проходит через сервисный слой в исходящий адаптер. Мой вопрос как раз в другом - допускает ли такая архитектура при необходимости прямое обращение из входного адаптера (визуальная форме) к исходящему адаптеру (DocumentRepository)?
Похоже не совсем понимаю проблему у автора комментария. В одном DTO добавляю поля Tags, а в другом DTO нет таких полей, если они не нужны в функционале использующем DTO.
В чём проблема извлечь все объекты Tag? Дайте нужные настройки при выполнении этого запроса.
Если речь идёт о работе с транзакциями, то конечно надо знать условия вызова commit/rollback.
Слой работающий с DTO более высоко лежащий, чем слой с Entity. И как раз слой с DTO знает всё про наличие и структуру Entity. И это вполне естественно, так как DTO наполняется данными из объектов Entity. А слой с Entity ничего не знает про слой с DTO. Такова логика многослойной архитектуры. Если ею не пользоваться, то ничего не могу сказать по этому вопросу.
Отличный комментарий - смешаны транзакции, Entity, LazyInitializationException и "слоеные архитектуры" как очередной marketing bullshit.
Но мне ответить очень легко.
DTO - это не обязательно какой-то аналог Entity. DTO может включать в себя информацию из разных Entity объектов и слой, содержащий DTO, конечно не имеет никакого отношения к тому как и где реализованы транзакции.
Что касается LazyInitializationException, то совершенно не обязательно, что Entity наполняется при помощи ORM фреймворка, который вызывает упомянутую исключительную ситуацию. Но даже при использовании ORM функционал слоя работающего с Entity должен быть реализован так, чтобы исключить возникновение LazyInitializationException.
Что касается транзакций, то типовой алгоритм следующий. Допустим работа с Entity идёт в logic layer. Функционал работающий с Entity помещается внутри функционала use case или по Фаулеру это application logic (это тоже logic layer). При старте метода в объекте application logic запускается транзакция, а затем отрабатывает нужный функционал с Entity. Если при работе метода не возникли exception, то по завершению функционала метода application logic отрабатывает commit транзакции, в противном случае rollback. Возникновение LazyInitializationException откатит транзакцию, а сообщение об этой ошибке покажет разработчику её источник.
Если использовать многослойную архитектуру, то ответ на этот вопрос очевиден. DTO находится в более высоко лежащем слое приложения, чем слой в котором находится Entity. Соответственно слой с Entity не знает, что существуют объекты DTO - слои связаны между собой однонаправленно. Поэтому маппинг Entity ↔ DTO происходит в слое в котором находятся объекты DTO.
Если FSD порождает столько проблем, которые описаны в статье и комментах, то возникает естественный вопрос, а зачем FSD вообще использовать. Берите многослойную архитектуру - она работает на всех масштабах от простейших приложений до огромных.
Наверное будет правильно так описать различия:
1) для приложения с визуальным интерфейсом "View" это "View Template" в который помещены данные "View model" и такой контент web-сервер отдаёт для прорисовки в броузере;
2) для веб-сервиса JSON-модель это data transfer object.
В идеальной модели газа отсутствует диссипация энергии и сингулярность связана с математическими свойствами уравнений, описывающих такую модель. В реальной модели - уравнение Навье-Стокса - скорее всего нет таких сингулярностей и механизмы турбулентности возникают по совсем другой причине - в течении вихри крупного масштаба теряют устойчивость и распадаются на вихри более мелкого масштаба. Более того возможно уравнение Навье-Стокса в известном сейчас виде и не описывает турбулентность. И для описания турбулентности требует какой-то модификации. Это сейчас очень обсуждаемый вопрос.
Сложно понять насколько ASP.Net MVC ещё используется в разработке? Судя по публикациям микросервисы полностью заняли его нишу разработки.
Переписывать код под акцию - это полная дичь. Все изменения цен под акции должны быть на уровне данных в бд, а код системы знает как пересчитывать цену конкретному покупателю под конкретную акцию.
Если приложение содержит доменную логику, то такая связь должна быть. Если этой связи нет, то встречный вопрос - кто будет запускать алгоритмы доменной логики?
В указанной автором статьи книге авторов Гарри Персиваль, Боб Грегори в итоговой общей схеме архитектуры почему-то выпала связь между блоком обработчиков (handlers) и предметной областью (domain). Эта связь многократно указана в книге - например в рисунке 7.5. Но в итоговой схеме её нет. Если приложение содержит функционал домена (предметную область), то нельзя обойтись без связки handlers -> domain.
Каким образом принцип наименьшего действия Лагранжа связан с нейросетью? Там классическая механика (набор материальных точек с ненулевой массой) с набором законов сохранения. Как это переносится на нейросеть?
Это как усечённый вариант космического туризма от Безоса. Тот поднимает на 100 км, а здесь не более 10 км.
Меня давно интересовал случай, когда в саге упадёт откат одной из транзакций - тогда и "eventual consistency" не удастся достигнуть. Поэтому при работе например с деньгами никак нельзя уйти от two-phase commit или работать только с одной бд (но такое часто бывает невозможно).
Юз кейс принадлежит слою application logic, который находится выше слоя доменной логики. Домен ничего не знает про юз кейс, который его использует.
Мне кажется наиболее логичным вложить функционал, реализованный в CrossDomainCoordinator, в юз кейс "Отменить заказ" в виде метода или вложенного объекта.
Можно и другое вспомнить. По просьбам трудящихся расстрелять врагов народа, как бешенных собак.
Однако как возрос накал в обсуждении. За цитату из Фаулера уже ставят минус!!!
Из Вашего рисунка это как раз отлично видно, что запрос из входного адаптера всегда проходит через сервисный слой в исходящий адаптер. Мой вопрос как раз в другом - допускает ли такая архитектура при необходимости прямое обращение из входного адаптера (визуальная форме) к исходящему адаптеру (DocumentRepository)?