Введите бизнес-терминологию в имена переменных.

Домен – это область знаний, связанная с проблемой, которую мы пытаемся решить.

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

Domain Driven Design направлен на создание стратегического программного обеспечения на основе моделей предметной области и определяет две основные концепции для достижения этой цели.

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

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

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

Тематическое исследование

Business-to-Business (B2B) — это бизнес, который ведется между одной компанией и другой.

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

Поставщик хочет избежать дублирования усилий по ручной загрузке изображений с обеих сторон и просит ведущую компанию использовать внутренний API для обновления изображений своих продуктов.

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

• Поставщик сообщает группе разработчиков, что его внутренний API описывает атрибут mediaAssetID для уникальной идентификации объекта изображения в его домене.
• Взаимодействия по электронной почте происходят, чтобы прояснить, как создать путь URL для получения конечного объекта изображения с использованием атрибута mediaAssetID.

Понимать бизнес-концепции, прежде чем переводить их в исходный код

Вездесущий язык — это язык бизнеса. Технические имена не могут описывать бизнес-домен.

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

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

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

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

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

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

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

Следующий дизайн класса представляет фундаментальную концепцию в ментальной модели эксперта в предметной области.

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

Мне нравится делиться своими знаниями и опытом в Java-программировании, Собеседованиях по кодированию, Алгоритмах, Структурах данных, Чистом коде, Принципах SOLID, Распределенных системах, Spring Framework, Веб-сервисах, Разработке программного обеспечения и др. Технические темы.

Первоначально опубликовано на https://codersite.dev 27 августа 2022 г.