业务层反汇编和业务对象类型

业务逻辑层包含包含业务逻辑的业务对象。其中一些是持久的，这些是实体。实体及其逻辑构成模型。其中一些是无状态的，包含一些不适合任何实体职责的额外逻辑。这些对象是服务（也是Model？的一部分）。

然后还有一些助手/实用程序类，如Managers、Factories、Builders。目前这种拆卸是否正确？

还有一些对象不是实体或服务，可以包含状态。具有自己线程的活动对象。可以长寿。那些物体是什么？只是业务对象还是业务组件？

在我的项目中，我有设备类。起初，我把它当作Entity对象来处理，因为它存储在DB中。它包含自己的线程，该线程定期从实际设备中获取一些数据，并对这些数据进行一些复杂的逻辑处理。因此，它是一个活跃而长寿的物体。我意识到它不可能是一个实体，因为它是一个沉重/复杂、活跃和长寿的物体（或者它可以？？？）。所以我把它分成不同的类：

• DeviceDescriptor，现在是实体和
• 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命名空间下。但后来我认为，最好将其视为单独的组件/模块或功能，并将其放置在ProjectName.Devices的Core命名空间之外（以及其他辅助对象、存储库和实体-DeviceDescriptor）。你觉得怎么样？

你能告诉我我的命名空间组织是否正确吗？这不是DDD的指导。它是一个相当于3层的体系结构，其中一些概念借鉴了DDD。（存储库、聚合根、服务、模型）。

如有任何建议，我将不胜感激。