Доменно-ориентированный дизайн с переходами между состояниями - PullRequest
1 голос
/ 17 июня 2020

Нам необходимо разработать систему хранения данных. Есть 3 сервиса хранения: Dropbox, ZohoDocs и pCloud. Пользователь может подписаться на любую из служб хранения или вообще не подписываться. Каждая служба имеет свои собственные переходы между состояниями.

В дизайне, управляемом доменом, Пользователь является Агрегатом root в нашем ограниченном контексте с несколькими атрибутами, указанными ниже:

User <AggregateRoot> {
  userId
  name
  email
}

Dropbox, ZohoDocs и pCloud считаются Сущностями.

Подход № 1

Определяется отношение «один к нулю или одному»:

User(1) to Dropbox(0..1)
User(1) to ZohoDocs(0..1)
User(1) to pCloud(0..1)

Каждый объект предоставляет метод для выполнения переходов между состояниями.

Пользователь моделирует инвариант - Один пользователь может подписаться на любую из услуг

Подход №2

Мы представляем объект под названием «StorageService», который имеет отношение «Состав» с 3 службами.

Определяется отношение «один к нулю или одному»:

StorageService(1) to Dropbox(0..1)
StorageService(1) to ZohoDocs(0..1)
StorageService(1) to pCloud(0..1)

Пользователь имеет отношение «ассоциация» один к нулю или одному со службой хранения.

User(1) to StorageService(0..1)

Каждый объект предоставляет метод для выполнения переходов между состояниями.

StorageService моделирует инвариант - StorageService может состоять из одного обслуживание за один раз

Какой из двух подходов более осуществим и масштабируем? Есть ли здесь лучшие подходы?

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

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