Очень спорное утверждение. Ведь паттерн описывает то, как представление должно взаимодействовать с бизнес-логикой приложения и/или на оборот (в некоторых фокрах MVC).
DDD отличная архитектура, но ее никто не понимает.
ddd — это не архитектура, это подход (методология) для разработки доменной модели.
Clean Architecture отличная архитектура, но ее полная реализация имеет смысл для огромных приложений
Конечно писать обычный бложик с использованием «чистой архитектуры» не очень хорошая идея. Но Clean Architecture отлично подходит для отделения мух от котлет даже в небольших бизнес-приложениях.
MVC
View находится в одном слое с контроллером, отвечает за конечное отображение данных. Контроллер после получения данных из сервиса передает данные во View и возвращает View для отображения.
Каждый ваш микро-сервис это приложение, которое построено с использованием MVC-паттерна. От которого вы предлагаете отказаться выше:
Казалось бы тогда давайте возьмем MVC для микросервиса и на этом и остановимся. Но нет, такой велосипед нам не подходит.
Итого
На мой взгляд, KISS Architecture подходит для 80% проектов и обеспечивает плавную эволюцию проекта.
На мой взгляд ваша «KISS Architecture» — это обычная через чур раздробленная микросервисная архитектура каждый компонент которой построен на MVC. И не более того. Применять ее для простых приложения нет ни какого смысла — я с удовольствием сделаю выбор в пользу монолита и откажусь от кучи накладных расходов на тестирование и развертывание. А если применять вашу «архитектуру» к крупным приложениям, то вы просто погрязнете в лавине ваших моделек-контейнеров.
Этот архитектурный подход будет понятен всем разработчикам и для его применения на практике не нужно читать толстенные книги про DDD.
Очень хочется, что бы разработчики понимали главное — нет «серебряной пули». Каждый проект уникален и требует индивидуального подхода. Конечно если ваша компания не занимается массовой разработкой бложиков на микросервисах :).
На мой взгляд будет очень тяжело сохранять границы между слоями/типами Общее ядо и Расширения языка. Конечно же это вопрос договоренностей внутри команд(ы), но как мне кажется Расширения языка достаточно быстро дадут течь или превратятся в Common/Utils.
Если у кого то есть реальный опыт такого разделения кода, очень хотелось бы услышать комменты.
В одном из своих проектов я использую следующую структуру пакетов: \Acme\<Context Code>\Domain, \Acme\<Context Code>\Application, \Acme\<Context Code>\Infrastructure.
Соответственно имеется "общее ядро" (\Acme\Core) в виде отдельного контекста которое содержит необходимый код, сгруппированный по слоям Domain, Application, Infrastructure. На пример, слой Domain содержит:
Супертип доменного слоя
Базовые классы исключений для доменного слоя
Базовые классы событий домена
и т.д.
Я еще веду эксперименты над структурой пакетов. Но переход к указанной выше структуре в значительной степени структурировал код.
Про инкапсуляцию я понял, а вот про «другую» сторону не совсем
Различные типы исключений бросаются исходя из типа ошибки, а не из контекста. По этому «кастомных» типов исключений будет не так уж и много и большая часть из них будет совпадать по именованию с системными (прим. InvalidArgumentException). Я хотел у знать опыт коллег по цеху — кто придерживается данного подхода?
Вы используете генератор ID сущности, а затем передаете этот ID в конструктор. Чем этот подход лучше или хуже того, если создавать идентификатор внутри конструктора, на пример при помощи использования той же ramsey/uuid: $this->id = Uuid::uuid1()?
Использование библиотеки «webmozart/assert» — в документации указано "*All assertions in the Assert class throw an \InvalidArgumentException if they fail*." Это означает, что мы уже не можем работать с собственным «деревом» исключений в домене. На сколько это допустимо? Я в своих приложениях стараюсь использовать исключения от наследованные от собственного корня, для дальнейшего удобства работы с ними. Я думаю, что для разработки библиотек использование системных исключений более чем оправдано. Но при разработке приложения — это доставляет некоторые проблемы. Кто что думает по этому поводу?
Очень спорное утверждение. Ведь паттерн описывает то, как представление должно взаимодействовать с бизнес-логикой приложения и/или на оборот (в некоторых фокрах MVC).
ddd — это не архитектура, это подход (методология) для разработки доменной модели.
Конечно писать обычный бложик с использованием «чистой архитектуры» не очень хорошая идея. Но Clean Architecture отлично подходит для отделения мух от котлет даже в небольших бизнес-приложениях.
MVC
Каждый ваш микро-сервис это приложение, которое построено с использованием MVC-паттерна. От которого вы предлагаете отказаться выше:
Итого
На мой взгляд ваша «KISS Architecture» — это обычная через чур раздробленная микросервисная архитектура каждый компонент которой построен на MVC. И не более того. Применять ее для простых приложения нет ни какого смысла — я с удовольствием сделаю выбор в пользу монолита и откажусь от кучи накладных расходов на тестирование и развертывание. А если применять вашу «архитектуру» к крупным приложениям, то вы просто погрязнете в лавине ваших моделек-контейнеров.
Очень хочется, что бы разработчики понимали главное — нет «серебряной пули». Каждый проект уникален и требует индивидуального подхода. Конечно если ваша компания не занимается массовой разработкой бложиков на микросервисах :).
А книги читать надо, в том числе и про ДДД.
На мой взгляд будет очень тяжело сохранять границы между слоями/типами Общее ядо и Расширения языка. Конечно же это вопрос договоренностей внутри команд(ы), но как мне кажется Расширения языка достаточно быстро дадут течь или превратятся в Common/Utils.
Если у кого то есть реальный опыт такого разделения кода, очень хотелось бы услышать комменты.
В одном из своих проектов я использую следующую структуру пакетов:
\Acme\<Context Code>\Domain,\Acme\<Context Code>\Application,\Acme\<Context Code>\Infrastructure.Соответственно имеется "общее ядро" (\Acme\Core) в виде отдельного контекста которое содержит необходимый код, сгруппированный по слоям Domain, Application, Infrastructure. На пример, слой Domain содержит:
Я еще веду эксперименты над структурой пакетов. Но переход к указанной выше структуре в значительной степени структурировал код.
Добрый день.