Звучит тривиально? Это не. Короткое замыкание между проблемой и решением — самая частая ошибка, которую совершают люди, находящиеся под давлением, а мы все находимся под давлением.

Продолжая обзор, который я написал в статье Дизайн, ориентированный на предметную область, — прорывной язык для технического письма, сегодня я хочу сосредоточиться на ядре разработки решения: отделении решения от проблемы. Звучит тривиально? Это не.

Чтобы понять почему, давайте обратимся к Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy Влада Хононова (неаффилированная ссылка).

Все начинается с людей

В самом начале книги Хононова есть краткое напоминание о простой истине, о которой часто забывают люди в индустрии программного обеспечения:

DDD напоминает нам, что разработчики программного обеспечения — не единственные, кто занимается созданием программного обеспечения.

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

Почему? Потому что деловые люди являются представителями проблемы и ценности ее решения. Они перемещаются в проблемное пространство.

Разработчики программного обеспечения перемещаются в пространство решений, которое является ценой решения проблемы.

Люди имеют значение.

Тогда важен настрой

Разработка программного обеспечения — это вертикальная область знаний. Это важно для создания программного обеспечения: это очевидно. Тем не менее, требуется больше, потому что разработка программного обеспечения как дисциплина сосредоточена на решении, но разработчики программного обеспечения сохраняют контроль над решением только тогда, когда бизнес-сфера решения четко определена.

Что такое бизнес-домен? Снова цитирую Хононова:

Бизнес-домен определяет основную область деятельности компании. Вообще говоря, это услуга, которую компания предоставляет своим клиентам.

И

Для достижения целей и задач своей бизнес-области компания должна работать в нескольких поддоменах. Поддомен — это детальная область деловой активности.

Звучит подавляюще? Так бывает, если вы являетесь членом команды разработчиков программного обеспечения, который должен создать решение и имеет строгие сроки выполнения. Вот причина, по которой короткое замыкание между проблемой и решением является простой ошибкой: поспешность.

И неадекватное мышление, которое приводит к поспешности в управлении мышлением и действиями людей.

Бизнес-домен и его поддомены определяют контекст проблемы. Короткое замыкание происходит, когда разработка программного обеспечения продолжается без укрощения этого контекста и немедленно создает решение — вероятно, неэффективное решение из-за отсутствия стратегии.

Стратегия

Стратегический дизайн — это первый этап DDD. Именно здесь проблема находится в центре внимания, и помните, что это проблема, которая приносит пользу.

Вернемся к людям. Для разработки стратегии требуются специалисты в предметной области. Легко ошибиться, если считать экспертами в предметной области некоторых опытных бизнес-аналитиков или даже разработчиков программного обеспечения. Вместо этого снова цитирую Хононова:

Эксперты предметной области не являются ни аналитиками, собирающими требования, ни инженерами, разрабатывающими систему. Эксперты домена представляют бизнес. Это люди, которые в первую очередь определили бизнес-проблему и от которых исходят все бизнес-знания.

Эксперты домена обеспечивают язык бизнеса. Вездесущему языку я посвящу целую статью; на данный момент крайне важно понять, что язык бизнеса является основой разработки стратегии.

Стратегия направлена ​​на управление решениями путем определения границ различных поддоменов, составляющих бизнес. Именно бизнес-разбивка позволяет обнаружить:

  • Основной поддомен: это то, куда нужно инвестировать, потому что он представляет собой конкурентное преимущество в решении бизнес-проблемы. Его бизнес-логика сложна.
  • Общий поддомен: здесь можно купить или передать решение на аутсорсинг, поскольку все компании на рынке делают то же самое.
  • Поддерживающий поддомен: здесь нужно платить за поддержку основного поддомена. Его бизнес-логика проста.

Тактика

Тактическое проектирование является вторым этапом DDD. Именно здесь в центре внимания находится решение, и помните, что решение — это цена решения проблемы.

Позвольте мне повторить важную истину: решение требует затрат. Решение — это цена, которую стоит заплатить, если проблема, которую оно решает, приносит пользу.

Тактический дизайн заслуживает отдельной статьи. Пока я упоминаю его только в сравнении со стратегическим дизайном, чтобы было очевидно, что тактический дизайн реализует бизнес-логику и как таковой является решением — своеобразной и отдельной системой мышления.

Заключение

Рецепт DDD для различения проблемы и решения содержит наиболее важный ингредиент: слова. Это язык, в котором «стратегия» и «тактика» имеют глубокое значение и перестают быть модными словечками для бессмысленных презентаций.

Вывод: проблема приносит пользу, а решение — это цена решения этой проблемы; Вот почему важно, чтобы они были различны.