业务逻辑层包含包含业务逻辑的业务对象。其中一些是持久的,那些是实体。实体及其逻辑构成模型。其中一些是无状态的,并且包含一些不适合任何实体职责的额外逻辑。这些对象是服务(也是模型的一部分?)。
然后是一些帮助器/实用程序类,例如 Managers、Factories、Builders。现在这个反汇编正确吗?
还有一些不是实体或服务的对象,它们可以包含状态。有自己的线程的活动对象。可以长寿。那些物体是什么?只是业务对象还是业务组件?
在我的项目中,我有 Device 类。起初我把它当作实体对象,因为它存储在数据库中。它包含自己的线程,定期从真实设备获取一些数据,并对这些数据执行一些复杂的逻辑。所以它是一个活跃而长寿的物体。我意识到它不能是一个实体,因为它是重/复杂、活跃和长寿的对象(或者它可以???)。所以我把它分成不同的类:
- DeviceDescriptor,现在是 Entity 和
- DeviceAccess(或 Device),包含复杂的业务逻辑,寿命长且活跃。它也是基于 DeviceDescriptor 对象进行初始化的。
这个 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 借来的一些概念的 3 层架构。(存储库、聚合根、服务、模型)。
我将不胜感激任何建议。