Разделение модулей на бизнес-уровне

Question

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

У нас есть 3 слоя АРХИТЕКТУРА а:

1. WebUI
2. Бизнес
3. DataRepositories

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

DataRepositories <--entities--> Business <--BO--> WebUI 

<--X--> средство связи с использованием объектов типа X.

Так мы имеем, например UserEntity как субъект и User в БО. Другой тип - билет, который снова имеет TicketEntity и Ticket.

В настоящее время у нас есть некоторые отдельные вертикальные срезы через слои, имеющие что-то вроде Accounts для пользователей в DataRepositories, Business и WebUI, которые хорошо определены и не взаимодействуют с другими срезами, такими как Tickets.

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

Чтобы быть более конкретным, у нас есть способ создания билета, который находится в Бизнес, и вызывается из WebUI. В качестве аргументов требуется информация о билете и «пользователе», который мы еще не знаем, если он должен быть объектом типа пользователя или просто имя пользователя/id. Если мы передадим пользовательский объект, презентация должна получить пользователя перед вызовом CreateTicket. Но, если webui передает идентификатор, бизнес-уровень должен разрешить пользовательский объект, который потребует добавления ссылки на бизнес-компонент «Пользователи» в Билетах (Бизнес).

Answer 1

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

Я обойду бизнес-объектами. Я подозреваю, что они не дают никакой ценности, которую вы можете назвать помимо неизменности и чужого понятия «архитектурной чистоты».

Мне также не нравится направление стрелки между объектами и репозиториями. Я бы хотел, чтобы хранилища знали об объектах, но не наоборот. Почему организация должна знать или ухаживать, если она сохраняется? Бизнес-логика и поведение должны быть неизменными.

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

Уровень данных должен отвечать за свою ссылочную целостность. Если билет должен быть подключен к JOIN, чтобы найти его пользователя, вы должны иметь его в слое данных.Когда запросы уровня сохранения сохраняются для пользователя, он также получит билеты, принадлежащие этому пользователю, и возвратит отношения «один к другому» в объектах. Пользователь будет иметь список или набор экземпляров билетов. Все это должно быть сделано на уровне обслуживания. Служба будет управлять сохранением, бизнес-объектами и другими службами, необходимыми для выполнения прецедента.