Абсолютно реальный проект с большим объёмом бизнес-логики и базами данных на десятки таблиц. Persistence layer сделан для работы с MSSQL или с Oracle. Переключение между MSSQL и Oracle делается в одном параметре в файле настроек проекта. ORM не используется. Всё построено на прямых sql запросах.
В тексте статьи подчёркивается зависимость presentation -> infrastructure, но на всех архитектурных схемах указано presentation -> application, что является совершенно логичным. В многослойной архитектуре самый верхний слой presentation, а самый нижний infrastructure. Если в приложении также присутствуют слои application и domain, то прямая зависимость presentation -> infrastructure представляется маловероятной.
В начале 2000х годов в планах было через 15 лет доставлять с Луны гелий-3 для использования на термоядерных электростанциях. Но не было меморандума об этом. Наверное потому ничего и не получилось.
В продвинутом курсе статистической физики (рекомендую прекрасную книгу Климонтовича "Статистическая физика") переход между упомянутыми выше тремя этапами описан в виде: уравнение Лиувилля -> уравнение Больцмана -> уравнение Навье-Стокса. И как раз переход уравнение Больцмана -> уравнение Навье-Стокса менее проблемный и его можно сделать несколькими разными способами. Фундаментальная проблема есть при переходе уравнение Лиувилля -> уравнение Больцмана и она состоит в том, что возникает необратимость при эволюции системы состоящей из множества элементов - в данном случае молекул. Уравнение Лиувилля - это обобщение для системы из огромного количества уравнений Гамильтона движения молекул среды. Это уравнения консервативной механики и они обратимы. В такой системе не возникает диссипация и эта система не движется к состоянию максимальной энтропии. Больцман математически несколько огрубил эту систему, она стала необратимой и за счёт этого её динамика движется к состоянию максимальной энтропии. Но вопрос остался открытым - за счёт чего возникает необратимость в системе, в которой молекулы упруго взаимодействуют между собой при помощи столкновений друг с другом.
Наблюдаю странную тенденцию - множество статей с описанием разных типов архитектуры. Но не вижу противоположной тенденции - формализовать и описать универсальную архитектуру и все вышеописанные виды архитектур будут только её проекциями под определённые виды проектов и задач.
То что описано в разделе "Новый подход: микросервис с DDD-Lite" этой статьи представляет собой классический вариант многослойной архитектуры. Слой, выше названый Interfaces, обычно называют Presentation layer.
Валидировать структуру DTO — это задача контроллера (через декораторы class-validator) или все же домена? Где хранить mapping Domain <-> DTO — в application слое или прямо в доменных сущностях метод .toDto()?
Слой работающий с DTO находится выше слоя домена. В общем случае взаимодействие между слоями однонаправленное. Из этого следует: 1) домен ничего не знает о существовании объектов DTO; 2) объекты DTO валидируются в Interfaces слое (нет смысла пробрасывать их дальше по слоям, если они невалидные); 3) mapping Domain <-> DTO находится в application слое.
Вы описываете идеальный случай. В реальности, если новый проект маленький, на него выделяют 1-2 разработчиков, которые должны уметь делать всё. Ну за исключением финального тестирования и написания документации.
В моём 1м комменте написано - бизнес-объект "температура" представляющий собой коллекцию объектов, в которой каждый объект содержит в себе данные об идентификаторе датчика, временном моменте измерения и значение температуры в этот момент. Бизнес-объект "температура" хранит всё измеренные значения или N последних измеренных значений.
Хорошее замечание. Но оно относится не к тому функционалу который изменяет, а к тому который отображает. Отображающий функционал должен учитывать разность во времени между текущим временем и временем последнего измерения. Если эта разность во времени превышает определённую дельту, то индикатор вместо температуры отображает "UNDEFINED".
Не совсем понял Ваш вопрос. Бизнес-объект температура содержит данные которые измерил датчик. Если датчик определил, что температура физически невозможна, то он не вносит новое значение в коллекцию объектов, которая находится внутри бизнес-объекта температура.
Если измеренная температура ниже -273.15°C, то объект-датчик не вносит её в бизнес-объект "температура", а в лог приложения или в специальный объект, собирающий информацию об ошибках измерений, вносит данные о возникшей ошибке измерения температуры.
Абсолютно реальный проект с большим объёмом бизнес-логики и базами данных на десятки таблиц. Persistence layer сделан для работы с MSSQL или с Oracle. Переключение между MSSQL и Oracle делается в одном параметре в файле настроек проекта. ORM не используется. Всё построено на прямых sql запросах.
В тексте статьи подчёркивается зависимость presentation -> infrastructure, но на всех архитектурных схемах указано presentation -> application, что является совершенно логичным. В многослойной архитектуре самый верхний слой presentation, а самый нижний infrastructure. Если в приложении также присутствуют слои application и domain, то прямая зависимость presentation -> infrastructure представляется маловероятной.
В начале 2000х годов в планах было через 15 лет доставлять с Луны гелий-3 для использования на термоядерных электростанциях. Но не было меморандума об этом. Наверное потому ничего и не получилось.
Очень изящно описан переход от уравнения Больцмана к Навье-Стоксу
По тематике этой статьи ближе всего книга Климонтовича.
В продвинутом курсе статистической физики (рекомендую прекрасную книгу Климонтовича "Статистическая физика") переход между упомянутыми выше тремя этапами описан в виде: уравнение Лиувилля -> уравнение Больцмана -> уравнение Навье-Стокса. И как раз переход уравнение Больцмана -> уравнение Навье-Стокса менее проблемный и его можно сделать несколькими разными способами. Фундаментальная проблема есть при переходе уравнение Лиувилля -> уравнение Больцмана и она состоит в том, что возникает необратимость при эволюции системы состоящей из множества элементов - в данном случае молекул. Уравнение Лиувилля - это обобщение для системы из огромного количества уравнений Гамильтона движения молекул среды. Это уравнения консервативной механики и они обратимы. В такой системе не возникает диссипация и эта система не движется к состоянию максимальной энтропии. Больцман математически несколько огрубил эту систему, она стала необратимой и за счёт этого её динамика движется к состоянию максимальной энтропии. Но вопрос остался открытым - за счёт чего возникает необратимость в системе, в которой молекулы упруго взаимодействуют между собой при помощи столкновений друг с другом.
Скорее всего понимается, что Entity это и есть DTO слоя инфраструктуры.
Наблюдаю странную тенденцию - множество статей с описанием разных типов архитектуры. Но не вижу противоположной тенденции - формализовать и описать универсальную архитектуру и все вышеописанные виды архитектур будут только её проекциями под определённые виды проектов и задач.
Этот комментарий можно легко оформить в виде отдельной статьи.
Редкий пример того, когда комментарий намного информативнее самой статьи.
Вытаптывание Сибири это что-то типа Нью-Васюки у Остапа Бендера.
То что описано в разделе "Новый подход: микросервис с DDD-Lite" этой статьи представляет собой классический вариант многослойной архитектуры. Слой, выше названый Interfaces, обычно называют Presentation layer.
Слой работающий с DTO находится выше слоя домена. В общем случае взаимодействие между слоями однонаправленное. Из этого следует: 1) домен ничего не знает о существовании объектов DTO; 2) объекты DTO валидируются в Interfaces слое (нет смысла пробрасывать их дальше по слоям, если они невалидные); 3) mapping Domain <-> DTO находится в application слое.
Вы описываете идеальный случай. В реальности, если новый проект маленький, на него выделяют 1-2 разработчиков, которые должны уметь делать всё. Ну за исключением финального тестирования и написания документации.
Юзкейсы и DDD - это про разное. Не представляю, как они могут мешать друг другу.
Первым этапом надо определиться с архитектурой. А паттерны - это следующий этап, когда понятно, какая архитектура должна быть реализована.
В моём 1м комменте написано - бизнес-объект "температура" представляющий собой коллекцию объектов, в которой каждый объект содержит в себе данные об идентификаторе датчика, временном моменте измерения и значение температуры в этот момент. Бизнес-объект "температура" хранит всё измеренные значения или N последних измеренных значений.
Хорошее замечание. Но оно относится не к тому функционалу который изменяет, а к тому который отображает. Отображающий функционал должен учитывать разность во времени между текущим временем и временем последнего измерения. Если эта разность во времени превышает определённую дельту, то индикатор вместо температуры отображает "UNDEFINED".
Не совсем понял Ваш вопрос. Бизнес-объект температура содержит данные которые измерил датчик. Если датчик определил, что температура физически невозможна, то он не вносит новое значение в коллекцию объектов, которая находится внутри бизнес-объекта температура.
Если измеренная температура ниже -273.15°C, то объект-датчик не вносит её в бизнес-объект "температура", а в лог приложения или в специальный объект, собирающий информацию об ошибках измерений, вносит данные о возникшей ошибке измерения температуры.