根据我对DDD概念的理解，所有与实体相关的应用功能都应该放在该实体中。
例如：UserEntity应该有register()注册功能。
然而，对于具有大量功能的大型应用程序而言，这没有意义。这意味着一个UserEntity类将是巨大的，因为它必须至少有一个方法用于每个功能。
我认为更好的方法是将register()抽象到自己的实体中：RegFuncEntity。
这意味着每个功能（例如，注册，登录，搜索用户，查看成员资格，支付账单等）被抽象到其自己的实体中。 UserEntity仍有方法，但只包含与User基本功能相关的方法（例如updateAddress()，updateFirstName()，updateSSN()，validate()等）。 reRegFuncEntity可以使用UserEntity（即功能实体可以使用此＆＃34;核心＆＃34;实体）。
我的问题是：这种设计是否贫血和/或仍然遵循DDD？
答案 0 :(得分：4)
Domain Driven Design为您提供了一个称为bounded context的强大工具。您的用户将在不同的有界上下文中执行不同的操作。例如：User BC中的User Management将login()，changePassword()和User实体可能是聚合根。
在另一个BC中，比如说Order，User实体将提供其他功能，而在这个BC中，User不能是聚合根（事实上，我是＆＃39; ll告诉你更多：它可能是一个价值对象。）
然后，每个BC将有一个User实体。在DDD中，相同的单词在不同的上下文中可能具有不同的含义（和行为）（这被称为普遍存在的语言）。 DDD中的常见示例是Order实体：这意味着要为运营商转发某些内容，为管理层收取费用等等。
如果领域专家使用同一个词来谈论您可能发现新BC的不同事物，UL甚至可以发现不同的有界背景。
UL的另一个提示是：谈论领域专家的语言：不要为用户使用UserEntity，而只是User，非程序员工作人员将难以理解实体。
在此过程之后，如果您在多个有界上下文之间共享某些功能，则可以查看共享内核。