Дизассемблирование бизнес-уровня и типы бизнес-объектов

Уровень бизнес-логики содержит бизнес-объекты, содержащие бизнес-логику. Некоторые из них настойчивы, это Сущности. Сущности вместе со своей логикой составляют модель. Некоторые из них не имеют состояния и содержат некоторую дополнительную логику, не укладывающуюся в обязанности какой-либо сущности. Эти объекты являются службами (также являются частью модели?).

Затем есть несколько вспомогательных / служебных классов, таких как менеджеры, фабрики, строители. А пока эта разборка верна?

Затем есть объекты, которые не являются сущностями или службами и могут содержать состояние. Активный объект, имеющий собственный поток. Может прожить долго. Что это за объекты? Просто бизнес-объекты или, может быть, бизнес-компоненты?

В моем проекте есть класс устройства. Сначала я относился к нему как к объекту Entity, потому что он хранится в БД. Он содержит собственный поток, который периодически получает данные с реального устройства и выполняет с этими данными сложную логику. Так что это активный и долгоживущий объект. Я понял, что это не может быть Сущность, потому что это тяжелый / сложный, активный и долгоживущий объект (или может ???). Поэтому я разделил его на отдельные классы:

  • DeviceDescriptor, который теперь является Entity и
  • DeviceAccess (или Device), содержащий сложную бизнес-логику, долговечен и активен. Он также инициализируется на основе объекта DeviceDescriptor.

Что за Business Objects представляет собой этот объект DeviceAccess?

Если у меня есть проект с такой структурой, где должен быть размещен объект Device / DeviceAccess в иерархии пространств имен?

  • ProjectName.Core - основные объекты, бизнес-объекты
  • ProjectName.Core.Entities - постоянные бизнес-объекты
  • ProjectName.Core.Services - интерфейсы сервисов
  • ProjectName.Core.Services.Default - реальная реализация сервисов
  • ProjectName.Core.Repositories - (уровень DAL) интерфейсы репозиториев
  • ProjectName.Core.Repositories.SqlServer - реальная реализация репозиториев

Сначала я подумал, что мне следует поместить этот объект в пространство имен Core. Но потом я подумал, что, может быть, лучше рассматривать его как отдельный компонент / модуль или функцию и поместить его вне пространства имен Core в ProjectName.Devices (вместе с другими вспомогательными объектами, репозиториями и сущностями - DeviceDescriptor). Что вы думаете?

Не могли бы вы также сказать мне, правильна ли моя организация пространства имен? Это не было указанием DDD. Это скорее трехуровневая архитектура с некоторыми концепциями, заимствованными из DDD. (Репозиторий, Совокупный корень, Услуги, Модель).

Буду признателен за любой совет.


c# namespace-organisation domain-driven-design business-logic-layer
person userx01233433    schedule 24.06.2013    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Уровень бизнес-логики содержит бизнес-объекты, содержащие бизнес-логику. Некоторые из них настойчивы, это Сущности. Сущности вместе со своей логикой составляют модель. Некоторые из них не имеют состояния и содержат некоторую дополнительную логику, которая не укладывается в обязанности какой-либо сущности. Эти объекты являются службами (также являются частью модели?).

Домен будет содержать агрегаты, сущности, объекты значений, события, службы и т. Д. Сущность просто означает концепцию, имеющую жизненный цикл и идентифицируемую идентификатором.

Затем есть несколько вспомогательных / служебных классов, таких как менеджеры, фабрики, строители. А пока эта разборка верна?

Что такое менеджеры? Представляют ли они концепцию в предметной области? Фабрику лучше всего реализовать в совокупном корне или сущности. Подумайте var post = forum.PostBy(user);. Строители могут помочь вам создавать сложные объекты, поддерживая язык. Например; carBuilder.PaintedIn(red).Spinning(bigRims)....

Затем есть объекты, которые не являются сущностями или службами и могут содержать состояние. Активный объект, имеющий собственный поток. Может прожить долго. Что это за объекты? Просто бизнес-объекты или, может быть, бизнес-компоненты?

Может быть, вы ищете Saga или Process Manager?

В моем проекте есть класс устройства. Сначала я относился к нему как к объекту Entity, потому что он хранится в БД. Он содержит собственный поток, который периодически получает данные с реального устройства и выполняет с этими данными сложную логику. Так что это активный и долгоживущий объект. Я понял, что это не может быть Сущность, потому что это тяжелый / сложный, активный и долгоживущий объект (или может ???). Поэтому я разделил его на отдельные классы ..

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

Если у меня есть проект с такой структурой, где должен быть размещен объект Device / DeviceAccess в иерархии пространств имен?

ProjectName.Core - основные объекты, бизнес-объекты ProjectName.Core.Entities - постоянные бизнес-объекты ProjectName.Core.Services - интерфейсы служб ProjectName.Core.Services.Default - реальная реализация служб ProjectName.Core.Repositories - (уровень DAL) интерфейсы репозиториев ProjectName.Core.Repositories.SqlServer - реальная реализация репозиториев

Рассматривали ли вы пространство имен, основанное на функциональности, а не на технических моделях? Здесь приведен пример команд пространственного именования на основе функциональности.

person JefClaes    schedule 27.06.2013