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

Domain

Понимание предметной области, для которой вы пишите программу, также важно, как и умение программировать. Это не значит, что её нужно знать досконально — иногда область может быть по-настоящему сложной (например, те же бухгалтерия или технологическое производство). Но общее понимание всё же требуется.

Рассмотрим в качестве примера Хекслет, так как вы с ним достаточно хорошо знакомы. Вы неплохо знаете его предметную область, хотя вряд ли думали о ней так, как мы сделаем это сейчас. В первую очередь, для её понимания нужно выделить ключевые понятия. У обучающих ресурсов это, как правило, "курс" и "урок", но на самом деле понятий гораздо больше. В случае Хекслета ещё можно выделить "профессию", "испытание" (практика после курса), "code review", "квиз" (набор вопросов и ответов), "участника курса" (вы становитесь участником, когда вступаете в курс), "проект". Этот список можно продолжать ещё долго. Вероятно, вы удивитесь, но на Хекслете существует более двухсот подобных понятий, которые также называют сущностями, и все они описаны в коде.

Сущности находятся в некоторых взаимоотношениях друг с другом. Например, квиз содержит (агрегирует) в себе вопросы. А каждый вопрос, в свою очередь, содержит в себе ответы. Профессия состоит из курсов, курсы из уроков, уроки — из теории, квиза и практики. Эти связи имеют конкретные названия. Например:

  • Один урок может находиться только в одном курсе, но курс содержит множество уроков. Такая связь называется "один ко многим" (one-to-many или o2m).
  • Один курс могут проходить множество пользователей, и один пользователь может проходить много курсов. Такая связь уже называется "многие ко многим" (many-to-many или m2m).
  • Реже встречается отношение "один к одному" (one-to-one или o2o). На Хекслете так связаны пользователь и эксперт.

ERD

В реальности всё ещё чуть сложнее, потому что одна и та же сущность с точки зрения разных систем может выглядеть совершенно по-разному. Пользователь Хекслета с точки зрения бухгалтера (а у нас есть бухгалтер!) и пользователь с точки зрения ментора — две большие разницы.

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

Далеко не всегда можно однозначно сказать, какая связь существует между двумя сущностями. Иногда программисты думают наперёд и сразу формируют более сложные связи, например, m2m, а не o2m, что сказывается на сложности кода. Чем сложнее связь, тем больше кода и выше стоимость её создания и поддержки. Сложность связей можно описать так: o2o, o2m, m2m, правее — сложнее. Иногда программисты ошибаются при выборе той или иной связи, что обычно говорит о недостаточно хорошем понимании предметной области. Приведу интересный пример. Предположим, что в системе нужно реализовать пользователя и заграничный паспорт. Интуитивно кажется, что между этими понятиями связь один к одному: ведь один пользователь может иметь один заграничный паспорт. Так? Не совсем: паспорт может поменяться, если он был утерян или закончился его срок действия. К тому же, в некоторых странах разрешено владение одновременно несколькими заграничными паспортами.

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

В зависимости от языка меняется способ представления сущностей в коде. В некоторых определяются типы (используя АТД, интерфейсы или классы), в других — структуры, а третьи вообще не предоставляют никаких вариантов, кроме словарей (ассоциативных массивов).

Со следующего урока мы начнём изучать различные предметные области и строить подходящие модели данных.

DDD

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


Дополнительные материалы

  1. Онтология
  2. Предметно-ориентированное проектирование
  3. ER-модель
Мы учим программированию с нуля до стажировки и работы. Попробуйте наш бесплатный курс «Введение в программирование» или полные программы обучения по Node, PHP, Python и Java.

Хекслет

Подробнее о том, почему наше обучение работает →