Структура каталога проекта (пакета, модуля)
На этапе разработки проекта разделение структуры каталогов часто рассматривается как первый шаг к успеху. Этот шаг часто сопровождается множеством компромиссов (соображений), как правило, двух соображений: деловых и технических.
- Бизнес-соображения включают: ограниченные контексты, поддомены, бизнес-модули.
- Технические соображения включают: архитектуру программного обеспечения (многоуровневая архитектура, гексагональная архитектура), классификацию стереотипов.
структура каталогов
Структура каталогов общих проектов в основном состоит из четырех частей: имя домена (domain), имя слоя (layer), имя стереотипа (stereotype) и имя бизнес-модуля (module).
Имя домена (бизнес домена, поддомена)
Домен в доменно-ориентированном проектировании обычно относится к бизнес-домену, который представляет собой конкретную область бизнеса. Бизнес в подобных проектах может быть схожим, но для большинства проектов решение бизнеса (проблемы) не будет выходить за рамки бизнес-домена, поэтому в проектеСтруктура каталогов (пакетов, модулей)который содержит бизнес-доменимяможет игратьограничениеэффект. Например: поддомен каталога товаров (Каталог), поддомен заказа (Заказ), поддомен логистики (Доставка), поддомен счета-фактуры (Счет-фактура) и так далее.
Иерархические имена в иерархической архитектуре
в структуре каталогов проектаявныйВведение имен слоев является техническим соображением, а точнее соображением кодирования. Многоуровневая архитектура — это решение (архитектурный паттерн) от хаоса к порядку. Это достигается путем разделения приложения (процесса) на группы подзадач, где каждая группа подзадач находится на определенном уровне абстракции. Например: Многоуровневая архитектура. В процессе внутренней разработки системы приложений система приложений часто делится на трехуровневую или четырехуровневую архитектуру.
Трехуровневая архитектура:
- Уровень представления
- Слой бизнес-логики (Бизнес)
- Упорство
Четырехуровневая архитектура:
- Уровень представления
- Прикладной (логический) уровень (Приложение)
- Уровень домена (Домен)
- Уровень инфраструктуры
в четырехуровневой архитектуреуровень инфраструктурычем трехуровневая архитектураслой сохраняемостибольше функций.
Многоуровневая архитектура в разработке прикладных систем не является строго многоуровневой архитектурой. Настоящее иерархическое представление состоит в том, что верхний уровень может зависеть только от нижнего уровня, что является односторонней зависимостью, а двусторонней зависимости быть не может. В частности, он имеет следующие характеристики:
- Слой J зависит от слоя J-1, а слой J+1 зависит от слоя J.
- Слой J-1 не зависит от слоя J, а слой J не зависит от слоя J+1.
- Слой J+1 также не зависит от слоя J-1.
переход между слоямиданныеизупаковка, конвертацияилиИспользовать напрямуюизолировать.
В погоне за производительностью и гибкостью появилось два варианта многоуровневой системы: упрощенная многоуровневая система и многоуровневая структура через наследование. Мы кратко обсудим слабослоистые системы, так как обычно применяемые системы используютсвободная система слоев.
Свободное многоуровневое представление системы: каждый уровень может использовать свои базовые службы, а не только службы следующего уровня. Каждый уровень может быть полупрозрачным, что означает, что некоторые сервисы видны только вышестоящему уровню, а некоторые сервисы видны всем вышележащим уровням.
Даже строго многоуровневая архитектура или свободная многоуровневая архитектура указывает на то, что верхний уровень зависит от нижнего уровня. Однако эта зависимость не полностью соблюдается в архитектуре реальной прикладной системы, потому что архитектору необходимо постоянно мыслить между монолитной архитектурой и многоуровневой архитектурой. Например: интерфейс репозитория на уровне доменаКласс реализацииЧасто размещается в инфраструктурном (Infrastructure) слое, что явно нарушает многоуровневую архитектуруОдносторонняя зависимостьсвязь. У такой проблемы есть два решения: одно — это признать. Второй — преобразовать интерфейс репозитория в доменный слой.Класс реализацииРазмещается внутри доменного слоя.
Название стереотипа (стереотип)
Стереотипы обозначаются номерами заголовков (>), которые используются для различения различных элементов моделирования.
Такие как: сущность, перечисление, исключение, запрос, событие, репозиторий, служба, контроллер и т. д. — все это распространенный стереотип.
Пополнить: к элементу моделирования в 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). В то же время при разделении структуры каталогов вы также можете использовать модуль, чтобы сначала разрезать по горизонтали.