当写由标准适用于I具有以下性质数据库中每个表的应用程序：CreatedOn，CreatedBy，ModifiedOn，ModifiedBy，Archived。域模型中的DDD - CreatedBy/CreatedOn？
但试图跟随DDD我在质疑这些属性是否真的是域的一部分，应该包含在域对象中。如果我要从域中排除这些“元数据”属性，但仍然希望它们在我的数据库中，那么如果要使用ORM，则需要实现某种DTO层。
因此，域模型被映射到DTO，CreatedOn，ModifiedOn等被设置，然后推送到数据库。
，所以我想我的问题是：
在进行域驱动设计时，您的实体通常不会与数据库的结构有很大关系。
您很快就会发现，无论如何，您需要在ORM的表格对象和域的聚合之间进行映射。
强迫数据库驱动的方面进入您的领域模型与DDD的全部内容相矛盾。
所以，我建议将ORM的表格对象（无论如何都是纯数据）映射到您的聚合中。这是Repository模式的起点。它将通过转换基础数据来提供域的对象。
如果像创建/修改日期和用户这样的元数据本身不是业务领域的一部分（即系统范围的日志需求），则可以在转换回表对象时注入给定用户和日期/时间保存。
一个分层的体系结构可能看起来像下面这样：
----------------------------
| Domain | (Aggregates)
----------------------------
----------------------------
| Repositories | (transforms table-objects into Aggregates)
----------------------------
----------------------------
| OR-Mapper | (loads records from DB into table-objects)
----------------------------
----------------------------
| Database | (this is where the data lives)
----------------------------
找到答案的唯一方法是询问您的产品所有者这些字段是否与您的模型相关。如果它们是，它们与哪些相关？
如果我排除域这些“元数据”的属性，但仍希望他们在我的数据库那么我会[.....]
为什么？它们不是模型的一部分，这意味着它们不属于你的域中任何逻辑的一部分。
3.是否有替代方案可以减轻执行某种形式的审计日志这样的问题？
如果审核日志是需求，那么他们应该是模型的一部分。
那么，在一个数据较重的系统中，例如CRM或ERP，通常需要跟踪谁做了什么以及什么时候完成。如果您考虑一个具有您可能想象的所有属性和功能的“客户”域实体，那么该客户是由该域的一部分创建或修改的？我想从你所说的话来看，如果这是信息存在的业务要求，那么它可能是域的一部分。 – David
CRM不太适合领域驱动的设计。 DDD擅长建模复杂的业务领域，而不是构建像CRM这样的通用系统。不过，你可以像DDD无知一样借用DDD的东西。 – jgauffin
@jgauffin CRM。当作为任务导向工具正确实施时，它是DDD的一个很好的候选者。我们已经逐渐认识到，CRM往往不是这样，因为它们往往是纯粹的CRUD系统，DDD并不适合。但即使在主要CRUDdy CRM中，也有部分或有界的上下文，DDD很可能适用。 –
我，表示国家需要的“元数据”不是一定是域的一部分其他的答案一致。
如果您的域名是身份和访问控制域，那么您将拥有涉及的用户名等。对于使用Identity和Access BC的任何事情，情况可能会有所不同。您可能需要以值对象的形式将一些用户信息添加到您的域中。
大多数情况下，我觉得这些数据属于应用程序服务级别。为了填充相关的数据库字段，您可以选择让存储库有权访问的应用程序服务填充一些上下文对象。通过这种方式，它不在你的模型中。
换句话说，在某个阶段可能需要优化的大规模系统中，DTO层将不可避免？ – David
@大卫。我稍微扩展了我的答案。 –