Я часто вижу этот термин в контексте архитектуры программного обеспечения («доменная модель», «доменный дизайн» и т. Д.). Я прогуглил это, но я получаю тонны различных определений. Так что это на самом деле?

Слово «домен» в книге Эрика Эванса «Управляемый доменом» имеет особое значение. В этом суть программного обеспечения.

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

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

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

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

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

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

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

Поэтому, хотя мы часто говорим о «домене» в программном обеспечении, в случае с DDD это не так просто, как может показаться.

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

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

Конкретным примером домена может быть что-то вроде «автоматизированной обработки сложных деталей с использованием высокоскоростного вращающегося резака». Программно-аппаратная система, которая выполняет это, называется станом с ЧПУ .

Другим примером домена является бухгалтерия корпорации.

Дальнейшее чтение
ограниченного контекста Мартина Фаулера

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

Домен представляет собой область знаний. Это может быть как деятельность, в которой существуют проблемы, решаемые вашим программным обеспечением. ( Wiki , DDD Community )

Эрик Эванс в своей книге использует грузовые перевозки, чтобы объяснить, что такое DDD. В его примере домен - это все о доставке . Как груз перемещается, управляется, отправляется и отслеживается и т. Д. Он имеет свои особые правила, язык и процессы. Они будут создавать доменные модели, объекты, сервисы и так далее.

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

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

Эрик Эванс: Из доменно-ориентированного проектирования: борьба со сложностями в основе программного обеспечения

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

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

Область бухгалтерской программы - деньги и финансы.

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

Модель предметной области, тогда, является «строго организованной и избирательной абстракцией» знаний в голове эксперта в предметной области.

Палермо, описывая архитектуру лука, предложил это резюме

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

Фаулер, в свою очередь, предлагает

Объектная модель домена, которая включает в себя как поведение, так и данные.

Если вы посмотрите на более свежие определения, вы, скорее всего, натолкнетесь на ссылки, что модель предметной области и модель данных различаются . Я не считаю, что изменение значения так же сильно, как изменение акцента - моделирование поведения (способ, которым данные изменяются в ответ на информацию извне модели), имеет более высокую сложность и вариацию, чем различные способы записи вещей. ,

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

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

Домен

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

Суб-домены

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

Доменная модель

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

Ограниченные контексты

Самое главное, что ограниченный контекст является логической границей.

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

Что дальше?

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