Проектирование на основе доменов - это методология и методическое задание для разработки сложных систем, цель которых - сопоставить действия, задачи, события и данные в проблемной области с технологическими артефактами в области решения.
Основной упор в доменно-ориентированном проектировании - понять проблемную область, чтобы создать абстрактную модель проблемной области, которая затем может быть реализована в определенном наборе технологий. Доменно-управляемый дизайн в качестве методологии содержит рекомендации о том, как разработка этой модели и разработка технологий могут привести к созданию системы, которая отвечает потребностям людей, использующих ее, и в то же время будет устойчивой к изменениям в проблемной области.
Процессная сторона Domain Driven Design включает в себя сотрудничество между экспертами по доменам, людьми, которые знают проблемную область, и экспертами по дизайну / архитектуре, людьми, которые знают домен решений. Идея состоит в том, чтобы иметь общую модель с общим языком, чтобы, когда люди из этих двух разных областей со своими двумя разными взглядами обсуждали решение, они фактически обсуждают общую базу знаний с общими понятиями.
Отсутствие общего понимания проблемной области между людьми, которым нужна определенная система, и людьми, которые проектируют и внедряют систему, кажется основным препятствием для успешных проектов. Домен-управляемый дизайн является методологией для устранения этого препятствия.
Это больше, чем объектная модель. На самом деле основное внимание уделяется общению и улучшению совместной работы, чтобы можно было обнаружить реальные потребности в проблемной области и создать соответствующее решение для удовлетворения этих потребностей.
Управляемый доменом дизайн: «Добро и вызов» дает краткий обзор этого комментария:
DDD помогает находить архитектуру верхнего уровня и информировать о механике и динамике области, которую программное обеспечение должно реплицировать. Конкретно, это означает, что хорошо выполненный анализ DDD сводит к минимуму недоразумения между экспертами в области и архитекторами программного обеспечения и уменьшает последующее количество дорогостоящих запросов на изменение. Разбивая сложность предметной области на более мелкие контексты, DDD избегает принуждения архитекторов проектов к разработке раздутой объектной модели, в которой много времени теряется при разработке деталей реализации - отчасти потому, что число сущностей, с которыми приходится иметь дело, часто выходит за рамки размер конференц-зала белые доски.
Также ознакомьтесь с этой статьей « Управляемый доменом дизайн для сервисной архитектуры», в котором приведен краткий пример. В статье приведено следующее описание миниатюрного доменного дизайна.
Доменно-управляемый дизайн поддерживает моделирование, основанное на реальных условиях бизнеса, в соответствии с нашими вариантами использования. Сейчас он стареет и уровень рекламы снижается, многие из нас забывают, что подход DDD действительно помогает понять проблему и разрабатывает программное обеспечение для общего понимания решения. При создании приложений DDD говорит о проблемах как доменов, так и поддоменов. Он описывает независимые шаги / области проблем как ограниченные контексты, подчеркивает общий язык для обсуждения этих проблем и добавляет много технических понятий, таких как сущности, объекты-значения и совокупные корневые правила, для поддержки реализации.
Мартин Фаулер написал несколько статей, в которых в качестве методологии упоминается доменно-управляемый дизайн. Например, эта статья, BoundedContext , предоставляет обзор концепции ограниченного контекста из разработки, управляемой доменом.
В те молодые годы нам посоветовали построить единую модель всего бизнеса, но DDD признает, что мы узнали, что «полное объединение модели предметной области для большой системы не будет возможным или экономически эффективным» 1 . Таким образом, вместо этого DDD разделяет большую систему на ограниченные контексты, каждый из которых может иметь унифицированную модель - по сути, способ структурирования MultipleCanonicalModels.