业务逻辑层包含包含业务逻辑的业务对象。其中一些是持久的，那些是实体。实体及其逻辑构成了Model。其中一些是无状态的，并且包含一些不适合任何实体职责的额外逻辑。那些对象是服务（也是Model的一部分？）。
然后有一些帮助/实用程序类，如Managers，Factories，Builders。 现在拆卸是否正确？
然后有些对象不是实体或服务，可以包含状态。具有自己的线程的活动对象。可以长寿。那些物品是什么？只是Business Objects或业务组件？
在我的项目中，我有Device类。起初我将它视为Entity对象，因为它存储在DB中。它包含自己的线程，定期从实际设备获取一些数据，并使用该数据执行一些复杂的逻辑。所以它是一个活跃且长寿的对象。我意识到它不能是一个实体，因为它是重/复杂，活跃和长寿的对象（或者它可以???）。所以我将它拆分为不同的类：
此DeviceAccess对象是什么类型的Business Objects？
如果我的项目结构如此，那么Device / DeviceAccess对象应该放在命名空间层次结构中？
首先我认为我应该将此对象放在Core命名空间下。但后来我认为将其视为单独的组件/模块或功能可能更好，并将其置于Core名称空间之外的ProjectName.Devices（以及其他帮助程序对象，存储库和实体 - DeviceDescriptor）。你觉得怎么样？
你能告诉我我的命名空间组织是否正确吗？这不是DDD的指导。它是三层架构，其中一些概念来自DDD。 （存储库，聚合根，服务，模型）。
我将不胜感激任何建议。
答案 0 :(得分：0)
业务逻辑层包含包含业务的业务对象 逻辑。其中一些是持久的，那些是实体。实体沿着 用它的逻辑制作模型。其中一些是无国籍的，包含 一些不适合任何实体责任的额外逻辑。那些 对象是服务（也是模型的一部分？）。
域将包含聚合，实体，值对象，事件，服务等。实体仅仅意味着具有生命周期并由id标识的概念。
然后有一些帮助/实用程序类，如Managers，Factories， 建设者。现在拆卸是否正确？
什么是经理？它们代表域中的概念吗？工厂最好在聚合根或实体上实现。想想var post = forum.PostBy(user);。构建者可以帮助您构建复杂的对象，支持语言。例如; carBuilder.PaintedIn(red).Spinning(bigRims)...。
然后有些对象不是实体或服务而且可以 包含国家。具有自己的线程的活动对象。可以长 住了。那些物品是什么？只是商业对象或商业 组件？
也许您正在寻找的是Saga或流程经理？
在我的项目中，我有Device类。起初我像实体一样对待它 对象，因为它存储在DB中。它包含自己的线程 定期从真实设备中获取一些数据并做一些复杂的事情 具有该数据的逻辑。所以它是一个活跃且长寿的对象。一世 意识到它不能成为一个实体，因为它是沉重/复杂的 和活跃的和长寿的对象（或它可以???）。所以我把它拆分成了 单独的班级..
它绝对可以是一个实体，可能是一个聚合根。你在组成多个价值对象的实体吗？值对象是封装逻辑的好方法。
如果我的项目结构如下，应该在哪里 Device / DeviceAccess对象是否放在命名空间层次结构中？
ProjectName.Core - 核心对象，业务对象 ProjectName.Core.Entities - 持久性业务对象 ProjectName.Core.Services - 服务接口 ProjectName.Core.Services.Default - 真正的服务实现 ProjectName.Core.Repositories - （DAL层）存储库接口 ProjectName.Core.Repositories.SqlServer - 真正的实现 存储库
您是否考虑过基于功能而非技术模式的命名空间？ Here是基于功能的命名空间命令的示例。