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

Создаваемые нами программные системы — это решения проблем бизнеса. Мудрый человек однажды сказал:

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

Как говорит Альберто Брандолини, разработка программного обеспечения — это процесс обучения; рабочий код — это побочный эффект. Программистам не остаётся другого выбора, кроме как овладеть умениями предметной области, чтобы понять проблему и решить её. В этой главе мы рассмотрим инструмент, который предметно-ориентированное проектирование предоставляет для эффективного обмена знаниями.

Можно с уверенностью сказать, что практически все проекты по разработке программного обеспечения требуют сотрудничества заинтересованных сторон всех ролей: экспертов предметной области, владельцев продукта, инженеров, дизайнеров пользовательских интерфейсов, менеджеров проектов, тестировщиков, аналитиков и других. Как в любом коллективном усилии, результат зависит от того, насколько хорошо все эти стороны могут работать вместе. Например, согласны ли все заинтересованные стороны в том, какая проблема решается? А что насчёт решения, которое они разрабатывают: есть ли у них какие-либо конфликтующие предположения относительно его функциональных и нефункциональных требований? Согласие и гармония по всем вопросам, связанным с проектом, являются залогом его успеха.

Исследования причин неудач в разработке программных продуктов показали, что эффективная коммуникация необходима для обмена знаниями и успеха проекта. Тем не менее, несмотря на важность, эффективная коммуникация в проектах по разработке программного обеспечения наблюдается редко. Часто бизнесмены и инженеры не имеют непосредственного взаимодействия друг с другом. Вместо этого информация о предметной области инженерам передаётся от экспертов предметной области. А доставляется она через людей, выполняющих роль посредников или «переводчиков» — системных/бизнес-аналитиков, владельцев продукта и менеджеров проектов.

В течение традиционного жизненного цикла разработки программного обеспечения, знания о предметной области «переводятся» в удобную для инженеров форму, известную как аналитическая модель — описание требований системы, отображающее лежащее в его основе понимание области. Несмотря на благие намерения, такая посредническая роль опасна для обмена знаниями. В любом переводе информация теряется; в данном случае знание предметной области, которое необходимо для решения бизнес-проблем, теряется в пути к инженерам-программистам. Потеря информации может привести к разработке неправильных решений или правильных решений для неправильных проблем — в обоих случаях результат один: неудачные проекты по разработке программного обеспечения.

Предметно-ориентированное проектирование предлагает более эффективный способ передачи инженерам знаний от экспертов предметной области — с использованием единого языка (ubiquitous language).

Использование единого языка является ключевой практикой предметно-ориентированного проектирования. Идея проста и наглядна: если стороны должны эффективно общаться, они должны говорить на одном языке.

Хоть это и здравое утверждение, но как сказал Вольтер: «Здравый смысл присущ не всем» (Common sense is not so common). Традиционный жизненный цикл разработки программного обеспечения предполагает следующие «переводы»:

• Знание предметной области в аналитическую модель
• Аналитическую модель в требования
• Требования в модель системы (system design)
• Модель системы в код

Вместо непрерывного «перевода» знаний о предметной области, предметно-ориентированное проектирование предполагает выработку универсального способа описания предметной области: единого языка.

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

Только через постоянное использование единого языка и понимание его терминов можно достичь понимания между всеми участниками проекта.

Крайне важно подчеркнуть, что единый язык — это язык бизнеса. Значит, он должен состоять только из терминов, относящихся к предметной области. Никакого технического жаргона! Ваша цель не в том, чтобы обучать экспертов синглтонам и абстрактным фабрикам. Цель единого языка состоит в том, чтобы сформировать понимание эксперта и модель предметной области в доступных терминах.

Допустим, мы работаем над системой управления рекламными кампаниями. Рассмотрим следующие утверждения:

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

Все эти заявления сформулированы на языке бизнеса. То есть они отражают экспертную точку зрения на предметную область.

С другой стороны, следующие утверждения чисто технические и, следовательно, не соответствуют понятию единого языка:

• iframe рекламы отображает HTML-файл.
• Кампанию можно опубликовать только в случае наличия хотя бы одной связанной записи в таблице active-placements.
• Комиссии с продаж основаны на связанных записях из таблиц transactions и approved-sales.

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

Единый язык должен быть точным и согласованным. Он должен исключить предположения и сделать явной логику предметной области.

Поскольку двусмысленность мешает коммуникации, каждый термин единого языка должен иметь только одно значение. Давайте рассмотрим несколько примеров неясных терминов и то, как эти ситуации можно улучшить.

Допустим, в какой-то предметной области термин «политика» имеет несколько значений: это может быть регулирующее правило или страховой договор. Точное значение можно уточнить при межличностном взаимодействии, в зависимости от контекста. Однако программное обеспечение плохо справляется с двусмысленностью и моделирование сущности «политика» в коде усложняется.

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

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

Термины-синонимы на первый взгляд могут казаться безобидными. Однако в большинстве случаев они указывают на разные понятия. В этом примере «посетитель» и «аккаунт» технически относятся к пользователям системы; однако в большинстве систем незарегистрированные и зарегистрированные пользователи представляют разные роли и разное поведение. Например, данные о «посетителях» в основном используются для анализа, тогда как «аккаунты» фактически используют систему и её функциональность.

Предпочтительно использовать каждый термин явно в своём контексте. Понимание различий между используемыми терминами позволяет создавать более простые и ясные модели и реализации сущностей предметной области.

Теперь рассмотрим единый язык с точки зрения моделирования.

Модель не является копией реального мира, но это рукотворная схема, которое помогает нам разобраться в системах реального мира.

Классическим примером модели является карта. Любая карта, включая навигационные карты, карты местности, карты мира, карты метро и т. д. — это модель.

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

У всех моделей есть цель и эффективная модель содержит столько деталей, сколько необходимо для выполнения её цели. Например, на карте мира не будут указаны станции метро. С другой стороны, карту метро нельзя использовать для оценки расстояний. Каждая карта содержит только информацию, необходимую для исполнения её предназначения.

Еще раз: полезная модель не является копией реального мира. Вместо этого модель предназначена для решения определённой задачи и должна предоставлять достаточно данных для достижения этой цели. Или, как сказал статистик Джордж Бокс: «Все модели неверны, но некоторые полезны».

При разработке единого языка мы фактически создаем модель предметной области. Язык, который мы используем, не должен охватывать все возможные детали бизнеса. Это было бы эквивалентно тому, чтобы сделать экспертом каждого участника проекта. Вместо этого единый язык должен включать достаточно аспектов предметной области, чтобы обеспечить возможность реализовать требуемую систему.

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

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

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

Как только единый язык сформулирован, его следует постоянно поддерживать на протяжении всего проекта: требования, тесты, документация и даже исходный код должны его использовать.

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

Единый язык — это краеугольный камень предметно-ориентированного проектирования. Он позволяет нам эффективно обмениваться знаниями о предметной области и способствует коммуникации между участниками проекта. Его следует использовать на всех этапах проекта — в разговорах, документации, тестах, диаграммах, исходном коде и т.д. Кроме того, единый язык должен быть согласованным — без неоднозначных и синонимичных терминов.

Крайне важно развивать язык по мере развития знаний о предметной области.