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

Слова важны. Они определяют, как мы воспринимаем мир, в который мы погружены. Возможно, поэтому слова word и world различаются на одну букву в английском языке.

Дизайн цифровых продуктов не является исключением.

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

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

Кто такие эксперты в области?

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

Кто такие инженеры-программисты?

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

Как мы видим, эти два профиля очень разные. Это почти не пересекающиеся роли. У них нет общих интересов, но они занимаются одним бизнесом. Наверняка они оба хотят, чтобы их компания была успешной.

Как они могут сотрудничать?

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

Этот метод не работает. Это очень похоже на «игру шепотом». Если вы этого не знаете, игра начинается с того, что один человек шепчет сообщение на ухо другому человеку, который передает его дальше, пока сообщение не дойдет до последнего участника, который произнесет его вслух. Результат сильно отличается от оригинала в 99% случаев.

Теперь представьте, что вы используете этот метод для ведения бизнеса. Инженеры-программисты будут создавать код, который не является тем, что эксперты в предметной области имели в виду в 99% случаев. Это означает вероятность отказа 99%. Плохо, да?!

Итак, как можно улучшить этот процесс?

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

Они ДОЛЖНЫ общаться!

Решение, предлагаемое структурой Domain-Driven Design (DDD), заключается в использовании общего языка среди заинтересованных сторон. Этот общий язык называется повсеместным языком. (Личное примечание к этому имени: это слово уродливое, и мне, как неанглоязычному писателю, этот термин очень сложно напечатать и запомнить 😆)

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

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

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

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

Человеческий фактор имеет решающее значение в преодолении проблем, необходимых для достижения целей вездесущего языка. Легко понять, что можно заявить об использовании общего языка, но тогда вы должны фактически определить, использовать его и использовать ВЕЗДЕ.

Вездесущий язык — это язык бизнеса. Таким образом, это должно быть определено экспертами предметной области. Чтобы было ясно, сказать, что вы хотите создать файл HTML, нельзя. Нет места для технического жаргона. Подумайте об этом, когда будете размещать свою следующую историю в JIRA в своей компании-разработчике программного обеспечения на основе DDD 😅

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

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

Третья задача — поддерживать актуальность языка. Бизнес не является статичным объектом, он постоянно развивается. Вездесущий язык — это язык бизнеса, и по мере развития бизнеса он должен соответствующим образом обновляться. Эксперты в предметной области и инженеры-программисты должны всегда быть «в курсе» и быть очень близко друг к другу, чтобы делиться эволюцией языка.

Выводы

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

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

Более того, это позволяет разработчикам программного обеспечения эффективно общаться с другими заинтересованными сторонами, что обычно является проблемой. Мы склонны использовать наш жаргон, чтобы нас считали умными. Но, в конце концов, мы создаем стены некоммуникабельности между нами и другими профессионалами в наших компаниях. Такое поведение может привести к отправке клиентам не того товара.

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

Это третья глава моего пути к изучению предметно-ориентированного проектирования.

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

Знаете ли вы видео, курсы или другие книги, которые я могу использовать в качестве справочного материала, чтобы по-настоящему понять эту тему? Я жду ваших предложений! 💚

Вот мои предыдущие статьи на эту тему: