Какую архитектуру приложения вы используете в проектах?

О, архитектура! Ну что, погнали разбирать этот цирк с конями, который зовётся современной джава-разработкой. Сидишь такой, думаешь — напишу пару контроллеров, ан нет, блядь. Теперь надо всю эту многослойную матрёшку выстраивать, а то опозоришься перед тимлидом, пидором шерстяным.

Вот смотри, чтобы не прослыть ламером, сейчас все пацаны в бэкенде юзают многослойную архитектуру (Layered Architecture). Но просто слои — это для лузеров, ёпта. К этому теперь приплетают ещё DDD (Domain-Driven Design), чтобы умно звучало, и гексагональную архитектуру (Ports & Adapters), от которой у меня, честно, иногда волнение ебать — не перепутай, куда что адаптировать.

Итак, слои, которые тебя ждут:

1. Presentation Layer (Контроллеры): Это твоё лицо, рожа проекта. Сидит, принимает HTTP-запросы (REST, GraphQL), проверяет, что ему принесли (эти ваши DTO), и отдаёт ответ. Главное — не проеб*ть валидацию, а то пользователь какую-нибудь дичь отправит.
2. Application Layer (Сервисы приложения): А вот тут уже начинается магия, или её иллюзия. Этот слой не делает нихрена сам, он такой дирижёр, орет на других. Его задача — организовать выполнение бизнес-операции: позвать доменный слой, сохранить что-то, отправить событие. Тут живут Use Cases или Application Services. Чувствуешь раздутость? Я — да.
3. Domain Layer (Ядро, святая святых): Вот тут, блядь, должна жить вся твоя бизнес-логика, ради которой всё и затевалось. Сущности (Entities), которые не просто геттеры-сеттеры, а с мозгами, объекты-значения (Value Objects) типа денег или адреса, агрегаты (Aggregates) — клубки из сущностей, и интерфейсы репозиториев (Repository Interfaces). Запомни: тут только интерфейсы! Реализация — в другом месте, ибо так модно.
4. Infrastructure Layer (Инфраструктура): Подвал, чердак и все коммуникации в одном флаконе. Здесь обитает вся техническая шелуха: доступ к базе (JPA, JDBC), общение с внешними API, отправка сообщений в Kafka, кэширование. Сюда же ты, страдалец, засунешь реализации тех самых репозиториев из доменного слоя. Разделение, мать его, concerns.

Как это всё в проекте выглядит, спросишь? Держи, любуйся:

com.example.order
├── application              // Слой приложения
│   ├── service             // Application Services (дирижёры)
│   ├── dto                 // Data Transfer Objects (почтальоны с данными)
│   └── command             // Команды для CQRS (если решил усложнить)
├── domain                  // Доменный слой (святое место)
│   ├── model               // Сущности, Агрегаты (Order, OrderItem)
│   ├── valueobject         // Объекты-значения (Money, Address)
│   ├── repository          // Интерфейсы репозиториев (OrderRepository)
│   └── service             // Доменные сервисы (логика, не влезающая в сущности)
└── infrastructure          // Инфраструктурный слой (технический ад)
    ├── persistence         // Реализации репозиториев (JPA Entity + Spring Data JPA)
    ├── web                 // REST Controllers (рожа проекта)
    └── messaging           // Адаптеры для Kafka/RabbitMQ (крикуны)

А если тебе мало, есть ещё "опциональные" плюшки, чтобы твой код стал совсем неподъёмным:

• CQRS (Command Query Responsibility Segregation): Идея гениальная — разделить модели для записи (Commands) и чтения (Queries). На практике это означает, что у тебя будет овердохуища классов, и иногда ты сам не поймёшь, где что искать. Зато масштабируется, блядь!
• Event-Driven Architecture: Это когда твои сервисы перестают напрямую орать друг на друга, а начинают кидаться бумажками-событиями (Events) через почтовый ящик (Kafka). Красиво, отвязано, а потом ищешь баг и понимаешь, что событие где-то потерялось, и ты просто сидишь и ждёшь у моря погоды. Пиздец, короче.

Вот такой вот конструктор для взрослых. Выглядит стройно, а когда начинаешь пилить, иногда хочется всё выкинуть и написать на голых сервлетах, честно. Но мода, блядь, она такая.