Domain Driven Design (DDD): структура каталога проекта (пакет, модуль)

Дизайн, управляемый доменом

Структура каталога проекта (пакета, модуля)

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

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

структура каталогов

Структура каталогов общих проектов в основном состоит из четырех частей: имя домена (domain), имя слоя (layer), имя стереотипа (stereotype) и имя бизнес-модуля (module).

Имя домена (бизнес домена, поддомена)

Домен в доменно-ориентированном проектировании обычно относится к бизнес-домену, который представляет собой конкретную область бизнеса. Бизнес в подобных проектах может быть схожим, но для большинства проектов решение бизнеса (проблемы) не будет выходить за рамки бизнес-домена, поэтому в проектеСтруктура каталогов (пакетов, модулей)который содержит бизнес-доменимяможет игратьограничениеэффект. Например: поддомен каталога товаров (Каталог), поддомен заказа (Заказ), поддомен логистики (Доставка), поддомен счета-фактуры (Счет-фактура) и так далее.

Иерархические имена в иерархической архитектуре

в структуре каталогов проектаявныйВведение имен слоев является техническим соображением, а точнее соображением кодирования. Многоуровневая архитектура — это решение (архитектурный паттерн) от хаоса к порядку. Это достигается путем разделения приложения (процесса) на группы подзадач, где каждая группа подзадач находится на определенном уровне абстракции. Например: Многоуровневая архитектура. В процессе внутренней разработки системы приложений система приложений часто делится на трехуровневую или четырехуровневую архитектуру.

Трехуровневая архитектура:

  • Уровень представления
  • Слой бизнес-логики (Бизнес)
  • Упорство

Четырехуровневая архитектура:

  • Уровень представления
  • Прикладной (логический) уровень (Приложение)
  • Уровень домена (Домен)
  • Уровень инфраструктуры

в четырехуровневой архитектуреуровень инфраструктурычем трехуровневая архитектураслой сохраняемостибольше функций.

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

  • Слой J зависит от слоя J-1, а слой J+1 зависит от слоя J.
  • Слой J-1 не зависит от слоя J, а слой J не зависит от слоя J+1.
  • Слой J+1 также не зависит от слоя J-1.

переход между слоямиданныеизупаковка, конвертацияилиИспользовать напрямуюизолировать.

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

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

relaxed-layers

Даже строго многоуровневая архитектура или свободная многоуровневая архитектура указывает на то, что верхний уровень зависит от нижнего уровня. Однако эта зависимость не полностью соблюдается в архитектуре реальной прикладной системы, потому что архитектору необходимо постоянно мыслить между монолитной архитектурой и многоуровневой архитектурой. Например: интерфейс репозитория на уровне доменаКласс реализацииЧасто размещается в инфраструктурном (Infrastructure) слое, что явно нарушает многоуровневую архитектуруОдносторонняя зависимостьсвязь. У такой проблемы есть два решения: одно — это признать. Второй — преобразовать интерфейс репозитория в доменный слой.Класс реализацииРазмещается внутри доменного слоя.

Название стереотипа (стереотип)

Стереотипы обозначаются номерами заголовков (>), которые используются для различения различных элементов моделирования.

stereotypes

Такие как: сущность, перечисление, исключение, запрос, событие, репозиторий, служба, контроллер и т. д. — все это распространенный стереотип.

Пополнить: к элементу моделирования в UML 1.4 и более поздних версиях можно прикрепить несколько стереотипов.

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

Название бизнес-модуля (модуль)

При анализе бизнес-домена (проблемы) бизнес-домен делится на несколько бизнес-модулей. например, вСубдомен магазинаСередина будет разделена на: персонал магазина (Staff), членов магазина (Member), роли магазина (Role) и так далее.

Классификация структуры каталогов

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

  • Имя бизнес-домена.Имя уровня.*
  • Имя бизнес-домена.Имя слоя.Имя бизнес-модуля.*
  • имя бизнес-домена.стереотипное имя.*
  • имя бизнес-домена.имя стереотипа.имя бизнес-модуля.*
  • имя бизнес-домена (имя слоя и имя стереотипа).*
  • Имя бизнес-домена. (Имя слоя и имя стереотипа). Имя бизнес-модуля.*
  • Имя бизнес-домена. Название бизнес-модуля.*
  • Имя бизнес-домена.Имя бизнес-модуля.Имя слоя.*
  • Имя бизнес-домена.Имя бизнес-модуля.Имя стереотипа.*
  • имя бизнес-домена.имя бизнес-модуля.(имя слоя и имя стереотипа).*
  • Имя бизнес-домена (имя бизнес-модуля, имя слоя и имя стереотипа).*
  • (стереотипное имя || имя слоя).Имя бизнес-домена.Имя бизнес-модуля.*

Дополнительные инструкции:

  • Опустите часть префикса обратного доменного имени пакета (org.mallfoundry.*).
  • поле какбизнес-домен, где имя бизнес-домена — это имя бизнес-домена, а не имя бизнес-домена.
  • (Имя слоя и имя стереотипа) представляет собой смесь, указывающую на то, что существует два способа разделения по слою и по стереотипу на одном и том же уровне структуры каталога (пакета).

Структура каталога: имя бизнес-домена.имя слоя.*

├─catalog            // 商品目录子域
│  ├─application
│  ├─domain
│  ├─infrastructure
│  └─presentation
├─order              // 订单子域
│  ├─application
│  ├─domain
│  ├─infrastructure
│  └─presentation
└─store              // 商家子域
    ├─application
    ├─domain
    ├─infrastructure
    └─presentation

Имя бизнес-домена.Имя слоя.Имя бизнес-модуля.*

├─catalog            // 商品目录子域
│  ├─application        // 应用层
│  │  ├─brand
│  │  ├─category
│  │  ├─collection
│  │  └─product
│  ├─domain             // 领域层
│  │  ├─brand               // 商品品牌模块
│  │  ├─category            // 商品类目模块
│  │  ├─collection          // 商品集合模块
│  │  └─product             // 商品模块
│  ├─infrastructure     // 基础设施层
│  │  └─persistent          // 持久化
│  │      ├─jpa
│  │      ├─mybatis
│  │      └─redis
│  └─presentation       // 表现层
│      ├─graphql
│      ├─grpc
│      ├─rest
│      ├─view
│      └─websocket
└─order
    ├─application
    │  ├─dispute
    │  ├─review
    │  ├─shipping
    │  └─source
    ├─domain
    │  ├─dispute
    │  ├─review
    │  ├─shipping
    │  └─source
    ├─infrastructure
    └─presentation

имя бизнес-домена.стереотипное имя.*

├─catalog
│  ├─controller
│  ├─exception
│  ├─model
│  ├─query
│  ├─repository
│  └─service
└─order
    ├─controller
    ├─exception
    ├─model
    ├─query
    ├─repository
    └─service

Примечание:

  • Пакет Model содержит модели предметной области, такие как сущности, объекты значений и перечисления. В некоторых проектах пакет Model будет называться: Pojo, Bean, Entity и т. д.
  • нажатиестереотипТакже будут структуры пакетов, такие как DTO и VO при разделении каталога.

имя бизнес-домена.имя стереотипа.имя бизнес-модуля.*

├─catalog
│  ├─controllers
│  │  ├─brand
│  │  ├─category
│  │  ├─collection
│  │  └─product
│  ├─exceptions
│  │  ├─brand
│  │  ├─category
│  │  ├─collection
│  │  └─product
│  ├─models
│  │  ├─brand
│  │  ├─category
│  │  ├─collection
│  │  └─product
│  ├─queries
│  │  ├─brand
│  │  ├─category
│  │  ├─collection
│  │  └─product
│  ├─repositories
│  │  ├─brand
│  │  ├─category
│  │  ├─collection
│  │  └─product
│  └─services
│      ├─brand
│      ├─category
│      ├─collection
│      └─product
└─order
    ├─controllers
    ├─exceptions
    ├─models
    ├─queries
    ├─repositories
    └─services

Примечание: при использовании этой структуры каталогов имя стереотипа частомножественное числоИменование формы.

имя бизнес-домена (имя слоя и имя стереотипа).*

├─catalog
│  ├─controller
│  ├─dao
│  ├─exception
│  ├─model
│  ├─query
│  └─service
└─order
    ├─controller
    ├─dao
    ├─exception
    ├─model
    ├─query
    └─service

Примечание: Гибридный подход (имя слоя и имя стереотипа) используется в структуре каталогов (пакетов), часто в проектах, которые путают многоуровневую архитектуру со стереотипами.

  • Контроллер представляет уровень представления.
  • Сервис представляет собой слой бизнес-логики.
  • Dao или Repository представляет уровень доступа к данным.
  • Модель представляет модель предметной области.

Имя бизнес-домена. (Имя слоя и имя стереотипа). Имя бизнес-модуля.*

├─catalog
│  ├─controller
│  │  ├─brand
│  │  ├─category
│  │  ├─collection
│  │  └─product
│  ├─dao
│  │  ├─brand
│  │  ├─category
│  │  ├─collection
│  │  └─product
│  ├─exception
│  │  ├─brand
│  │  ├─category
│  │  ├─collection
│  │  └─product
│  ├─model
│  │  ├─brand
│  │  ├─category
│  │  ├─collection
│  │  └─product
│  ├─query
│  │  ├─brand
│  │  ├─category
│  │  ├─collection
│  │  └─product
│  └─service
│      ├─brand
│      ├─category
│      ├─collection
│      └─product
└─order
    ├─controller
    ├─dao
    ├─exception
    ├─model
    ├─query
    └─service

Имя бизнес-домена. Название бизнес-модуля.*

├─catalog
│  ├─brand
│  ├─category
│  ├─collection
│  └─product
└─order
    ├─dispute
    ├─review
    ├─shipping
    └─source

Имя бизнес-домена.Имя бизнес-модуля.Имя слоя.*

├─catalog
│  ├─brand
│  │  ├─application
│  │  ├─domain
│  │  ├─infrastructure
│  │  └─presentation
│  ├─category
│  │  ├─application
│  │  ├─domain
│  │  ├─infrastructure
│  │  └─presentation
│  ├─collection
│  │  ├─application
│  │  ├─domain
│  │  ├─infrastructure
│  │  └─presentation
│  └─product
│      ├─application
│      ├─domain
│      ├─infrastructure
│      └─presentation
└─order
    ├─dispute
    ├─review
    ├─shipping
    └─source

Примечание: Слой будет внутри модуля.

Имя бизнес-домена.Имя бизнес-модуля.Имя стереотипа.*

├─catalog
│  ├─brand
│  │  ├─controller
│  │  ├─exception
│  │  ├─model
│  │  ├─query
│  │  ├─repository
│  │  └─service
│  ├─category
│  │  ├─controller
│  │  ├─exception
│  │  ├─model
│  │  ├─query
│  │  ├─repository
│  │  └─service
│  ├─collection
│  │  ├─controller
│  │  ├─exception
│  │  ├─model
│  │  ├─query
│  │  ├─repository
│  │  └─service
│  └─product
│      ├─controller
│      ├─exception
│      ├─model
│      ├─query
│      ├─repository
│      └─service
└─order
    ├─dispute
    ├─review
    ├─shipping
    └─source

Примечание: Стереотип будет внутри модуля.

имя бизнес-домена.имя бизнес-модуля.(имя слоя и имя стереотипа).*

├─catalog
│  ├─brand
│  │  ├─controller
│  │  ├─dao
│  │  ├─exception
│  │  ├─model
│  │  ├─query
│  │  └─service
│  ├─category
│  │  ├─controller
│  │  ├─dao
│  │  ├─exception
│  │  ├─model
│  │  ├─query
│  │  └─service
│  ├─collection
│  │  ├─controller
│  │  ├─dao
│  │  ├─exception
│  │  ├─model
│  │  ├─query
│  │  └─service
│  └─product
│      ├─controller
│      ├─dao
│      ├─exception
│      ├─model
│      ├─query
│      └─service
└─order
    ├─dispute
    ├─review
    ├─shipping
    └─source

Имя бизнес-домена (имя бизнес-модуля, имя слоя и имя стереотипа).*

├─catalog
│  ├─brand
│  ├─category
│  ├─collection
│  └─product            // Product 模块
│      ├─controller
│      ├─dao
│      ├─exception
│      ├─model
│      ├─query
│      ├─review             // Product 模块内的 Review 模块
│      │  ├─controller
│      │  ├─dao
│      │  ├─exception
│      │  ├─model
│      │  ├─query
│      │  └─service
│      └─service
└─order
    ├─dispute
    ├─review
    ├─shipping
    └─source

Примечание: (имя бизнес-модуля, имя слоя и имя стереотипа) Сочетание трех — это способ разделения каталога проекта (пакета). Эта структура имеет тенденцию выглядеть беспорядочно.

(стереотипное имя || имя слоя).Имя бизнес-домена.Имя бизнес-модуля.*

├─catalog
│  ├─brand
│  ├─category
│  ├─collection
│  └─product
├─order
│  ├─dispute
│  ├─review
│  ├─shipping
│  └─source
└─rest                  // 发布 RESTful 接口。
    ├─catalog
    │  ├─brand
    │  ├─category
    │  ├─collection
    │  └─product
    └─order
        ├─dispute
        ├─review
        ├─shipping
        └─source

Используйте модуль для разделения по горизонтали

В Java будут банки для организации модулей (Module).Мы можем использовать Module для разделения сначала по горизонтали, а затем разделить структуру каталогов внутри модуля.

Во-первых, субдомен Каталог и субдомен Заказа горизонтально разделены на четыре модуля:

  • catalog
  • catalog-rest
  • order
  • order-rest

Модуль: каталог

└─org.mallfoundry.catalog
    ├─brand
    ├─category
    ├─collection
    └─product

Модуль: каталог-остаток

└─org.mallfoundry.rest.catalog
    ├─brand
    ├─category
    ├─collection
    └─product

Модуль: заказ

└─org.mallfoundry.order
    ├─dispute
    ├─review
    ├─shipping
    └─source

Модуль: заказ-отдых

└─org.mallfoundry.rest.order
    ├─dispute
    ├─review
    ├─shipping
    └─source

Дублирование путаницы в именах (имя бизнес-модуля, имя слоя и имя стереотипа)

При первом просмотре незнакомого проекта три структуры (имя бизнес-модуля, имя слоя и имя стереотипа) могут быть перепутаны с одним и тем же именем.

вназвание бизнес-модуляСтруктура основного каталога (пакета) выглядит следующим образом:.repository.,.dao.С такой структурой каталогов вы можете сразу подумать о стереотипах или слоях. но.repository.,.dao.Скорее всего это просто бизнес-модуль репозитория или дао.

Суммировать

В проектах часто используется структура каталога (пакета), состоящая из четырех частей: доменного имени (domain), имени слоя (layer), имени стереотипа (stereotype) и имени бизнес-модуля (module). В то же время при разделении структуры каталогов вы также можете использовать модуль, чтобы сначала разрезать по горизонтали.