Стоит ли выбирать DDD?
Хоть я и обещал себе больше не возвращаться к теме DDD, но все таки добавлю еще пару слов на эту тему. Если коротко, то не делайте из еды культа. Посмотрите по сторонам.
Далее: Пара слов про Domain-Driven Design (DDD)
More …Итеративный процесс (Iterative Development) в DDD
Domain-Driven Design — это не про «нарисовать модель один раз и писать код по ней». Это про итеративный процесс, в котором доменная модель и код развиваются вместе: мы постоянно уточняем модель через общение с экспертами и тут же отражаем изменения в коде и в универсальном языке.
More …Тактическое проектирование (Tactical Design) в DDD
Тактическое проектирование (Tactical Design) — это набор строительных блоков Domain-Driven Design, из которых собирается сама доменная модель: сущности (Entities), объекты-значения (Value Objects), агрегаты (Aggregates), репозитории (Repositories), сервисы домена (Domain Services), фабрики (Factories) и события домена (Domain Events).
Контрольный список для тестирования проекта
Основной принцип — не тестируем то, что уже тестировали, и не тестируем очевидную логику. По умолчанию используется функциональное (BDD) тестирование. Unit-тесты пишутся только для логики, которую невозможно или неэффективно проверить через BDD-сценарии.
More …Контрольный список для логирования проекта
Данный документ описывает единые стандарты использования structlog в Python-проектах.
Соблюдение правил обеспечивает консистентность JSON-логов, удобство поиска в ELK/Grafana Loki и чистоту кода.