Как правильно разделять логику в проекте
От слоёв к границам: подход DDD и Clean Architecture
🔥 Почему слоистая архитектура не работает в долгую?
Типичный шаблон:
На старте удобно. Но со временем:
Причина? Мы разделяем по “техническим слоям”, а не по смыслу.
- Логика размазывается по слоям
- Классы растут до сотен строк
- Новые фичи ломают старые
Причина? Мы разделяем по “техническим слоям”, а не по смыслу.
✅ Что вместо: границы по смыслу
Правильный подход — строить систему вокруг предметной области.
Идея из DDD и Clean Architecture - разделяй по бизнес-контекстам и изолируй доменную логику.
Идея из DDD и Clean Architecture - разделяй по бизнес-контекстам и изолируй доменную логику.
💡 Пример: подтверждение заказа
❌ Плохой вариант — логика в сервисе
public void ConfirmOrder(Guid id) {
var order = _repo.GetById(id);
if (order.Status != Draft)
throw new Exception();
order.Status = Confirmed;
_repo.Save(order);
}Что не так?
Логика — не в заказе, а в сервисе. Сущность — просто DTO.
Логика — не в заказе, а в сервисе. Сущность — просто DTO.
✅ Хороший вариант — логика в домене
Теперь поведение — внутри сущности, как и должно быть:
public class Order {
public OrderStatus Status { get; private set; }
public void Confirm() {
if (Status != Draft)
throw new Exception();
Status = Confirmed;
}
}🧱 Архитектура: границы и зависимости
- Domain — центр, содержит правила и поведение
- Application — юзкейсы (что делает система)
- Infrastructure — базы, API, файлы
- Controller — просто адаптер
Каждый слой зависит только от внутреннего.
🧩 Bounded Context — разделение по смыслу
У вас может быть два модуля:
И в каждом — своя сущность User, со своим смыслом.
DDD называет это границами контекста. Они защищают смысл и упрощают разработку.
- Orders — логика заказов
- Payments — логика расчётов
И в каждом — своя сущность User, со своим смыслом.
DDD называет это границами контекста. Они защищают смысл и упрощают разработку.
🗂 Пример структуры проекта
Каждый контекст — как отдельное мини-приложение.
/src
/OrderManagement
/Domain
/Application
/Infrastructure
/Api
/PaymentManagement
...🎯 Что это даёт
- Чистая и предсказуемая архитектура
- Прозрачные границы
- Тестируемая бизнес-логика
- Проект проще масштабировать
🧠 Вывод
Слои — это техника.
Границы — это смысл.
Хорошая архитектура строится вокруг домена, а не базы данных и контроллеров.
Границы — это смысл.
Хорошая архитектура строится вокруг домена, а не базы данных и контроллеров.
🚀 Хочешь научиться делать архитектуру правильно?
У нас есть практический курс по DDD и Clean Architecture на C#/Go/Java.
- Разрабатываем реальный проект
- Всё по шагам, на практике
- С примерами и разбором ошибок
Понравилась статья? Поделись в соцсетях!