Начинаю серию постов о применении Domain-Driven Design на всех этапах создания продукта.
Как вы можете догадаться, в моей жизни, пришло сразу несколько команд и людей с вопросами про DDD...
Про DDD часто говорят так:
– «Это подход к проектированию»
– «Нет, это про моделирование кода!»
– «На тестировании нам DDD не нужен, там TDD»
– «Это для сложных систем, а мы MVP делаем»
DDD — не про что-то одно, это "сквозь миры". Это способ договариваться, думать, создавать и поддерживать сложные бизнес-системы через единый язык и модель предметной области.
В этой серии постов я хочу пройти по всем ключевым этапам разработки цифрового продукта до вывода на прод, и показать, как DDD помогает (и где мешает):
1) Сбор требований, работа со стейкхолдерами
2) Архитектура и проектирование
3) Разработка и реализация
4) Тестирование
5) Пост-документация и передача знаний
И сегодня про этап 1: Сбор требований и взаимодействие со стейкхолдерами.
Сам пост уже ниже 👇
#architecture #ddd