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

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

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

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

Ищите несогласованные термины и просите разъяснений. Например, если у одной вещи есть несколько названий — найдите причину. Эти разные названия используются в одном решении? Ищите контексты и делайте их явными. Если же значения одинаковые, то руководствуйтесь здравым смыслом и просите использовать один термин.

И последнее, но не по важности: как можно больше общайтесь с экспертами предметной области. Это не обязательно должны быть формальные встречи. Кулеры для воды и перерывы на кофе — отличные средства коммуникации. Обсуждайте предметную область с экспертами. Попробуйте использовать их язык. Ищите трудности в понимании и просите разъяснений. Не беспокойтесь, эксперты обычно с радостью сотрудничают с инженерами, которые искренне заинтересованы в изучении области задач!

Как сказал Джесси Уотсон в своей отличной статье «Сложность в разработке программного обеспечения»: «Самый ценный актив в индустрии программного обеспечения — это синтез навыков программирования и глубокого понимания контекста области задач в одной голове». Освоение единого языка и анализ предметной области компании — это кратчайший путь к пониманию контекста.

Выясните, чем занимается ваша компания. Какие сервисы она предоставляет своим клиентам? Чем она отличается от конкурентов, и какие вещи делают все компании в её отрасли одинаково?

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

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

Обращайте внимание на проблемы, которые можно решить с помощью паттернов интеграции контекстов:

Предохранительный уровень
Неудобные модели, оставшиеся из сервисов и устаревших систем

Сервис с открытым протоколом
Клиентам приходится постоянно следить за изменениями в услугах, которые они потребляют

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

В конечном итоге составьте карту контекста для более глубокого понимания стратегии.

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

Для снижения рисков лучше сначала разобраться с самим решением. Начните с разделения его на ограниченные контексты. Ищите конфликтующие модели. Определите неявные границы и сделайте их явными. На первых порах границы могут быть логическими (пространство имён или модули), а позже реорганизоваться в различные физические решения и кодовые базы.

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

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

Рефакторинг устаревшей кодовой базы в модель предметной области или модель предметной области, основанную на событиях не прост. Но он не обязательно станет проблемой.

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

Анализируйте границы транзакций. Есть ли решения, которые требуют строгой согласованности, но работают с нестрого согласованными данными? Или наоборот, использует ли решение строгую согласованность там, где бы хватило бы нестрогой? Анализируя кодовую базу, не забывайте, что эти решения принимаются в интересах бизнеса, а не технологий.

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

Говорите с экспертами предметной области. Покажите им модели, основанные на состояниях и событиях. Объясните различия и преимущества (особенно в отношении измерения времени), которые предлагает моделирование событий. Не исключено, что эксперты будут в восторге от уровня понимания, который предоставляет этот паттерн и будут сами настаивать на его использовании.

А вы, взаимодействуя с экспертами предметной области, не забывайте работать над единым языком!

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

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

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

Удачи!