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

Личная мотивация

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

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

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

Домен

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

Доменный язык

У каждого домена своя терминология, свой язык. Термин в одном домене означает нечто совершенно иное в другом домене.

Счет

Банковский счет позволяет нам отправлять и получать деньги и имеет уникальный номер. Каждый раз, когда мы говорим о счете в банке, счет всегда является банковским счетом. С другой стороны, учетная запись в информационной системе используется для авторизации пользователя. У нас есть термин «учетная запись», означающий что-то совершенно разное в двух разных областях. Домен влияет на то, что мы представляем, когда кто-то произносит конкретный термин. Итак, мы должны сначала изучить и указать доменные термины.

Цена

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

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

Вездесущий язык

Чтобы уменьшить двусмысленность естественного языка, мы можем ввести точный язык.

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

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

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

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

Влияние на модель

VIP Цена

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

Мы можем подумать о сценарии использования клиентов - нам нужна другая цена. А что будет, когда он попросит еще одну цену? Придется снова переписать программное обеспечение. Что, если обобщить эту задачу? Мы можем предложить неограниченное количество цен, введя прайс-листы. У продукта может быть цена в нескольких прайс-листах. Звучит хорошо, правда? Прикольная фишка - прайс-листы.

Ментальная модель

Клиент имеет в виду две цены на один и тот же товар.

Мы думаем о товарах, прайс-листах и ​​ценах

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

А теперь представьте, что клиент хочет снизить цену VIP. Для него это просто - он хочет изменить номер, который называется VIP-цена. Что это для программиста? Мы должны найти прайс-лист VIP, найти цену на данный продукт в прайс-листе и, наконец, изменить стоимость. Что будет, если прайс-лист не найдется? Если цена в прайс-листе не найдена? Теперь у нас есть варианты использования, которых нет в клиентском домене. Клиент не может объяснить, что должно произойти, потому что для него это не имеет смысла.

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

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

Эволюция домена

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

TL;DR

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

Такой простой, но такой мощный.

В следующий раз мы рассмотрим моделирование.

использованная литература

ЭВАНС, Эрик. Дизайн на основе предметной области: решение сложных задач в самой основе программного обеспечения. Бостон: Аддисон-Уэсли, 2004. ISBN 0–321–12521–5.

ФАУЛЕР, Мартин. Вездесущий язык. MartinFowler.com [онлайн]. 2006 [2017–11–28]. Доступно: https://martinfowler.com/bliki/UbiquitousLanguage.html

Контакт

Вы проектируете архитектуру и вам нравится подход DDD? Наймите меня, я могу вам помочь. Svatasimara.cz