Паттерны архитектуры приложений Spring Boot: здесь

Серебряной пули не существует. Когда речь заходит об архитектуре современного приложения, часто можно услышать, что Anemic Domain Model — это плохо, или что Transaction Script — это антипаттерн. Также многие советуют Clean Architecture или Hexagonal Architecture в связке с DDD как «лучшую» или «правильную» архитектуру.

Но бесплатных обедов не бывает. Любое решение всегда приходит со своим набором компромиссов. Важно понимать эти trade-offы и выбирать архитектуру, которая лучше всего подходит под конкретные требования приложения.

Если вы делаете микросервис для одного конкретного сабдомена, возможно, простой слоистой архитектуры будет вполне достаточно. Если это монолит с низкой или средней сложностью — модульный монолит может быть хорошим выбором. Но если вы строите сложную систему с высокой сложностью, несколькими сабдоменами, процессами и воркфлоу, тогда имеет смысл задуматься о модульном монолите с DDD и гексагональной архитектурой.

Может возникнуть вопрос: почему стоит довольствоваться «достаточно хорошей» архитектурой, а не сразу делать «лучшую»?

Ответ простой: всё упирается в соотношение стоимости и пользы. Архитектура «достаточно хорошего уровня» в большинстве случаев полностью закрывает потребности приложения и при этом её проще реализовывать, поддерживать и развивать, чем идеальную, но переусложнённую архитектуру.

Лично я считаю, что исправлять недоинженеренную систему проще, чем переинженеренную. Добавлять всегда легче, чем убирать.

Представьте, что вы работаете с большим существующим кодбейсом и на 99% уверены, что одна из библиотек нигде не используется. Но удалить её страшно — вдруг что-то сломается. С архитектурой та же история. Если вы однажды переусложнили решение, потом очень трудно это откатить или упростить.

Поэтому лучше начинать с архитектуры «достаточно хорошего уровня» и эволюционировать её по мере развития системы.

Именно это и демонстрируется в данном репозитории: реализация примера приложения с использованием разных архитектурных подходов. Начиная с простой слоистой архитектуры и постепенно переходя к модульному монолиту с DDD и гексагональной архитектурой. В каждом модуле дизайн и архитектура улучшаются за счёт применения лучших практик и паттернов.

👉 Java Portal