Что такое Domain-Driven Design (DDD) и каковы его основные концепции?

Так, слушай, смотри, есть такая штука — Domain-Driven Design (DDD). Это, блядь, не просто очередной модный фреймворк, который за неделю выучишь. Это, сука, целая философия, как не выстрелить себе в ногу, когда пишешь сложную бизнес-хуйню. Суть в чём? А суть в том, чтобы твой код не был оторван от реальности, а жил и дышал тем же, чем и бизнес-эксперты. Чтобы когда они говорят «списать со счёта», ты не думал про update balance set sum = sum - 100, а видел за этим, блядь, целую операцию с кучей правил, проверок и последствий. Чтобы не было этой ебалы, когда разработчики на своём тарабарском, эксперты — на своём, а в итоге получается пиздец и система, которая работает, но не так.

Основные киты, на которых всё держится, а точнее — не проваливается в сраку:

• Ubiquitous Language (Единый язык): Это когда все — от тестировщика до CEO — говорят на одном языке. Не «там кнопка, которая делает вот это», а «подтверждение заказа». И этот же термин, блядь, лезет прямо в код. Order.confirm(), а не SomeService.finalizeTransaction(). Иначе — пиши пропало, через полгода уже ни хуя не поймёшь, что тут происходит.
• Bounded Contexts (Ограниченные контексты): Вот это, ёпта, ключевое! Понимаешь, «клиент» в отделе продаж — это один чувак с контактами и историей звонков. А «клиент» в бухгалтерии — это, блядь, совсем другой субъект, у которого есть ИНН, договор и долги. Это РАЗНЫЕ сущности! И не надо их лепить в одну мега-модель User на 150 полей. Раздели, блядь, на SalesLead и LegalCounterparty. Каждый живёт в своём контексте, со своими правилами. Иначе получится монстр, которого невозможно ни понять, ни изменить.
• Сущности (Entities): Это те, кого можно опознать в лицо. У них есть ID, паспорт, так сказать. Заказ № 1488, Пользователь Вася Пупкин. Их состояние может меняться (Вася сменил адрес), но это всё ещё Вася.
• Объекты-значения (Value Objects): А это, наоборот, безликие, но важные характеристики. Адрес: Москва, ул. Пушкина, д. Колотушкина, кв. 1. Или Сумма: 100 рублей. У них нет своего ID. Два адреса с одинаковыми полями — это один и тот же адрес. Их не меняют, а создают новые. Проще, надёжнее, меньше геморроя.
• Агрегаты (Aggregates): А вот тут начинается магия, блядь. Это когда ты берёшь кучу связанных сущностей и объектов-значений и говоришь: «Ребята, вы теперь — одна банда». Например, Заказ (агрегат) — это корень. А внутри него — список ПозицийЗаказа (объекты-значения) и ссылка на Клиента (сущность). Весь внешний мир общается ТОЛЬКО с корнем Заказ. Хочешь добавить позицию? Не лезь напрямую в список, вызови order.add_item(...). Это чтобы инварианты (бизнес-правила) не разъебались. Например, чтобы нельзя было добавить позицию в уже оплаченный заказ. Всё контролируется в одном месте — в корне агрегата. Красота, ёпта!
• Репозитории (Repositories): Это такие привратники для агрегатов. Тебе не нужно знать, как там этот Заказ хранится — в PostgreSQL, в MongoDB или на хуй в файлике. Ты просто говоришь: «Репозиторий, дай мне заказ с ID 123» или «Сохрани этот заказ». Всё. Детали спрятаны. Работаешь с бизнес-моделью, а не с SQL-запросами.
• События домена (Domain Events): Это крики агрегата во внешний мир: «Эй, я только что подтвердился!» (OrderConfirmed). На это событие могут подписаться другие части системы: отправить письмо, списать товары со склада, начислить бонусы. Всё развязано, ничего ни о ком не знает, просто реагирует на события. Гибко, блядь, как мартышка на лиане.
• Сервисы домена (Domain Services): Бывает логика, которая не влезает ни в одну сущность. Ну, например, перевод денег со счёта на счёт. Это не метод счёта «списать», а потом другого «зачислить». Это отдельная операция, которая должна гарантировать кучу правил. Вот для этого и сервисы. Но без фанатизма, а то получится свалка процедурного кода.

Смотри, как это может выглядеть в коде (простой пример):

from typing import List

# Объект-значение. Неизменяемый, характеризуется полями.
class OrderItem:
    def __init__(self, product_id: str, quantity: int, price: float):
        if quantity <= 0: raise ValueError("Quantity must be positive")
        if price <= 0: raise ValueError("Price must be positive")
        self.product_id = product_id
        self.quantity = quantity
        self.price = price

    def total_price(self) -> float:
        return self.quantity * self.price

# Агрегат. Корень. Хранит в себе объекты-значения и рулит логикой.
class Order:
    def __init__(self, order_id: str, customer_id: str, items: List[OrderItem] = None):
        if not order_id: raise ValueError("Order ID cannot be empty")
        if not customer_id: raise ValueError("Customer ID cannot be empty")
        self.id = order_id
        self.customer_id = customer_id
        self._items = items if items is not None else []
        self.status = "Pending"

    def add_item(self, item: OrderItem):
        # Здесь может быть логика проверки инвариантов агрегата
        # Например, нельзя добавлять в отменённый заказ
        if self.status == "Cancelled":
            raise ValueError("Cannot add items to a cancelled order")
        self._items.append(item)

    def get_total_amount(self) -> float:
        return sum(item.total_price() for item in self._items)

    def confirm_order(self):
        if self.status == "Pending":
            self.status = "Confirmed"
            # Вот оно! Событие домена! Агрегат заявляет о факте.
            # Дальше кто-то другой (не он!) может на это отреагировать.
            # DomainEventPublisher.publish(OrderConfirmed(self.id))
        else:
            raise ValueError("Order cannot be confirmed from current status")

# Репозиторий. Абстракция над хранилищем. Работает только с целым агрегатом Order.
class OrderRepository:
    def save(self, order: Order):
        # Логика сохранения агрегата Order в базу данных
        print(f"Saving Order {order.id} with status {order.status} to DB...")
        # Например, ORM-операции или SQL-запросы

    def get_by_id(self, order_id: str) -> Order:
        # Логика загрузки агрегата Order из базы данных
        print(f"Loading Order {order_id} from DB...")
        # Возвращаем фиктивный объект для примера
        if order_id == "123":
            return Order("123", "cust_001", [
                OrderItem("prod_A", 2, 10.0),
                OrderItem("prod_B", 1, 25.0)
            ])
        return None

# Пример использования
# repo = OrderRepository()
# new_order = Order("123", "cust_001")
# new_order.add_item(OrderItem("prod_X", 1, 50.0))
# new_order.confirm_order()
# repo.save(new_order)
# loaded_order = repo.get_by_id("123")
# print(f"Loaded order total: {loaded_order.get_total_amount()}")

Короче, DDD — это не про то, чтобы сразу всё усложнить. Это про то, чтобы сначала, блядь, ПОНЯТЬ, что ты делаешь, а потом уже кодить. Это оружие против хаоса в больших и сложных проектах. Если у тебя простой бложик — забей хуй, не нужен он тебе. А если пишешь ядро банковской системы или маркетплейса — тогда, друг мой, это твой путь. Сначала мозги сломаешь, зато потом не будешь каждые два месяца переписывать всю хуйню с нуля, потому что «бизнес попросил фичу».