N‑tier это немного о другом. Каждый tier в N‑tier архитектуре должен быть реализован при помощи чистой, многослойной или какой-нибудь другой архитектуры. N‑tier - это solution architecture, а другие типы архитектуры из этой статьи - это application architecture.
Платеж теперь проходил быстро, а фрод догонял его и в случае чего откатывал транзакцию отдельным компенсирующим действием (Saga).
Вполне реален случай, когда после прохода платежа он автоматически перечисляется с этого счёта на новый счёт. И тогда после окончания проверки по фроду уже нельзя откатить транзакцию потому что на счету, на который произведён платёж, уже нет этих денег. Как такой вариант обрабатывается?
Это классическая 3х слойная архитектура: presentation layer, logic layer, persistence layer. Только не надо контроллер инжектировать во вьюв. В контроллере создается объект view model, содержащий нужные данные для вьюва, и view model инжектируется во вьюв. А сам пример построения архитектуры исключительно простой и наглядный.
Hibernate - промышленная технология. Очень широко используется. Вряд ли можно назвать её неудачной. Неудачными могут быть некоторые элементы этой технологии.
В первый раз вижу включения репозиториев во внутрь TransactionManager. Репозиториев могут быть сотни. До каких размеров тогда вырастет TransactionManager? Из моего опыта если в юз кейсе нужна транзакция, то транзакционный механизм описывается, как обёртка для этого юз кейса. Репозитории используются в функционале юз кейса. Транзакция открывается перед выполнением кода юз кейса. Если функционал юз кейса отработал без ошибок, то транзакция коммитится. В противном случае откатывается.
Не совсем понятно зачем нужна такая сложная цепочка Handler -> Outbox table -> Outbox poller -> Broker -> FastStream -> MessageBus для модульного монолита, который является единым приложением. Такая цепочка естественна для микросервисной архитектуры. Для модульного монолита достаточно Handler -> MessageBus. В чём здесь преимущество использования паттерна Outbox ?
Достаточно редкий пример статьи с полным описанием работы модульного монолита. У меня возник следующий вопрос.
Модульный монолит это отдельное приложение в рамках компьютера. Для варианта “In‑memory событийная шина” понятно как работают все EventHandler.
Для варианта “Внешний брокер сообщений” вижу такой сценарий. Каждый EventHandler должен запускать отдельный thread для просмотра списка сообщений в MessageBroker. При появлении нового сообщения, которое относится к конкретному EventHandler, этот хендлер запускает его обработчик. Уточните ваш вариант работы для “Внешний брокер сообщений”.
Фундаментальная проблема возникает при переходе от микроскопического уровня к мезоскопическому. На микроскопическом уровне уравнения механики обратимы во времени - нет никакой диссипации. На мезоскопическом уровне Больцман и позднее Боголюбов вводят некоторое огрубление математической модели, которое и приводит к необратимости во времени и соответственно возникает диссипация, ведущая в замкнутой системе к равномерному распределению молекул в пространстве через конечный интервал времени. Это соответствует второму началу термодинамики. Проблема в том как можно физически обосновать огрубление математической модели при переходе к мезоскопическому уровню описания.
В F35 там же не только поворотное сопло двигателя работает. Ещё есть схема отбора мощности двигателя для второго вертикального потока воздуха сразу за кабиной пилота. Такого раньше ни у кого не было. В целом инженерное решение F35 для вертикального взлёта/посадки это технический шедевр.
Когда-то пришлось поработать с СОМ-технологией и СОМ компонентами. Как на меня это полный ужас. Её создали очень сложные люди, которые не стремились к простоте и красоте того, что они делают.
Статья очень информативна в том плане, что детально разбирается архитектура реально работающего проекта. Но то каким образом представлена схема архитектуры на схеме модуля вызывает много вопросов.
Один модуль вызывает менеджер другого
Из схемы модуля видно что при обращении к модулю идёт вызов к Anti-Corruption Layer, а не к менеджеру модуля.
затем в принимающем модуле, внешнее DTO преобразуется во внутреннее, из доменного слоя
Внутреннее DTO наверное надо назвать доменным объектом.
Архитектуру приведенную на схеме модуля скорее можно назвать многослойной архитектурой, адаптированной для взаимодействия между модулями одного приложения. Обычно многослойная архитектура описывает взаимодействие приложения с другими приложениями.
На схеме модуля на мой взгляд не указаны или перепутаны порядок использования слоёв и направления взаимодействия между слоями.
Anti-Corruption Layer скорее всего это и есть слой Presentation через который идёт вызов к функционалу модуля и при вызове ему передаётся объект dto. Если в Presentation используется cron, то вызов проходит без передачи объекта dto.
На схеме не показано откуда идёт вызов к Application. Можно предположит, что вызов идёт от Anti-Corruption Layer.
Непонятно что именно понимается под блоком Components и где находится блок доменной логики?
Для наглядности архитектуру удобно разделить на 2 части - схема взаимодействия между слоями/функциональными блоками модуля и схема переноса данных между моделями данных модуля. Сейчас на схеме вызовы идут и через функциональные блоки и через модели данных.
Если мы говорим о Stateless-приложениях, а обычно веб-приложения являются такими, то ORM объектов, которые извлекли на предыдущем шаге юз кейса (например извлечение данных из бд, которые на следующем шаге надо изменить и записать в бд) уже не существует. И объект persistence model надо создавать с нуля с помощью данных соответствующего доменного объекта.
N‑tier это немного о другом. Каждый tier в N‑tier архитектуре должен быть реализован при помощи чистой, многослойной или какой-нибудь другой архитектуры. N‑tier - это solution architecture, а другие типы архитектуры из этой статьи - это application architecture.
Это ужас. Для учёта состояния карты отдельное поле - активная или неактивная. Или что-то в этом роде. Но точно не null.
Ужасный перевод
Вполне реален случай, когда после прохода платежа он автоматически перечисляется с этого счёта на новый счёт. И тогда после окончания проверки по фроду уже нельзя откатить транзакцию потому что на счету, на который произведён платёж, уже нет этих денег. Как такой вариант обрабатывается?
Это классическая 3х слойная архитектура: presentation layer, logic layer, persistence layer. Только не надо контроллер инжектировать во вьюв. В контроллере создается объект view model, содержащий нужные данные для вьюва, и view model инжектируется во вьюв. А сам пример построения архитектуры исключительно простой и наглядный.
Hibernate - промышленная технология. Очень широко используется. Вряд ли можно назвать её неудачной. Неудачными могут быть некоторые элементы этой технологии.
В моём комментарии указано что вся работа с транзакцией идёт в юз кейсе. Так было сделано во многих проектах.
В первый раз вижу включения репозиториев во внутрь TransactionManager. Репозиториев могут быть сотни. До каких размеров тогда вырастет TransactionManager? Из моего опыта если в юз кейсе нужна транзакция, то транзакционный механизм описывается, как обёртка для этого юз кейса. Репозитории используются в функционале юз кейса. Транзакция открывается перед выполнением кода юз кейса. Если функционал юз кейса отработал без ошибок, то транзакция коммитится. В противном случае откатывается.
Не совсем понятно зачем нужна такая сложная цепочка Handler -> Outbox table -> Outbox poller -> Broker -> FastStream -> MessageBus для модульного монолита, который является единым приложением. Такая цепочка естественна для микросервисной архитектуры. Для модульного монолита достаточно Handler -> MessageBus. В чём здесь преимущество использования паттерна Outbox ?
Достаточно редкий пример статьи с полным описанием работы модульного монолита. У меня возник следующий вопрос.
Модульный монолит это отдельное приложение в рамках компьютера. Для варианта “In‑memory событийная шина” понятно как работают все EventHandler.
Для варианта “Внешний брокер сообщений” вижу такой сценарий. Каждый EventHandler должен запускать отдельный thread для просмотра списка сообщений в MessageBroker. При появлении нового сообщения, которое относится к конкретному EventHandler, этот хендлер запускает его обработчик. Уточните ваш вариант работы для “Внешний брокер сообщений”.
Вайбкодингом сейчас занимаются в том числе и супер продвинутые разработчики.
Фундаментальная проблема возникает при переходе от микроскопического уровня к мезоскопическому. На микроскопическом уровне уравнения механики обратимы во времени - нет никакой диссипации. На мезоскопическом уровне Больцман и позднее Боголюбов вводят некоторое огрубление математической модели, которое и приводит к необратимости во времени и соответственно возникает диссипация, ведущая в замкнутой системе к равномерному распределению молекул в пространстве через конечный интервал времени. Это соответствует второму началу термодинамики. Проблема в том как можно физически обосновать огрубление математической модели при переходе к мезоскопическому уровню описания.
Поддержка транзакции на уровне юзкейсов - это типовой подход в многослойной архитектуре.
Очень напоминает гонения на генетику в советские времена.
В F35 там же не только поворотное сопло двигателя работает. Ещё есть схема отбора мощности двигателя для второго вертикального потока воздуха сразу за кабиной пилота. Такого раньше ни у кого не было. В целом инженерное решение F35 для вертикального взлёта/посадки это технический шедевр.
Когда-то пришлось поработать с СОМ-технологией и СОМ компонентами. Как на меня это полный ужас. Её создали очень сложные люди, которые не стремились к простоте и красоте того, что они делают.
Может есть смысл от обсуждения монолит vs микросервис, перейти к обсуждению вопроса компонент vs микросервис ?
Агрегат зависящий от набора флагов - это полный ужас.
Статья очень информативна в том плане, что детально разбирается архитектура реально работающего проекта. Но то каким образом представлена схема архитектуры на схеме модуля вызывает много вопросов.
Из схемы модуля видно что при обращении к модулю идёт вызов к Anti-Corruption Layer, а не к менеджеру модуля.
Внутреннее DTO наверное надо назвать доменным объектом.
Архитектуру приведенную на схеме модуля скорее можно назвать многослойной архитектурой, адаптированной для взаимодействия между модулями одного приложения. Обычно многослойная архитектура описывает взаимодействие приложения с другими приложениями.
На схеме модуля на мой взгляд не указаны или перепутаны порядок использования слоёв и направления взаимодействия между слоями.
Anti-Corruption Layer скорее всего это и есть слой Presentation через который идёт вызов к функционалу модуля и при вызове ему передаётся объект dto. Если в Presentation используется cron, то вызов проходит без передачи объекта dto.
На схеме не показано откуда идёт вызов к Application. Можно предположит, что вызов идёт от Anti-Corruption Layer.
Непонятно что именно понимается под блоком Components и где находится блок доменной логики?
Для наглядности архитектуру удобно разделить на 2 части - схема взаимодействия между слоями/функциональными блоками модуля и схема переноса данных между моделями данных модуля. Сейчас на схеме вызовы идут и через функциональные блоки и через модели данных.
Если мы говорим о Stateless-приложениях, а обычно веб-приложения являются такими, то ORM объектов, которые извлекли на предыдущем шаге юз кейса (например извлечение данных из бд, которые на следующем шаге надо изменить и записать в бд) уже не существует. И объект persistence model надо создавать с нуля с помощью данных соответствующего доменного объекта.