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

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

2 голосов
/ 26 июня 2011

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

У нас есть трехуровневая архитектура:

  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.

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

Если говорить точнее, у нас есть метод для создания заявки, которая находится в Business и вызывается из WebUI.Он принимает в качестве аргументов детали заявки и «пользователя», которых мы пока не знаем, должен ли он быть объектом типа user или просто username / id.Если мы передадим объект пользователя, то презентация должна получить пользователя до вызова CreateTicket.Но если webui передает идентификатор, то бизнес-уровень должен разрешить объект пользователя, для чего потребуется добавить ссылку на бизнес-компонент Users в Tickets (Business).

1 Ответ

2 голосов
/ 26 июня 2011

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

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

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

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

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

...