我已经阅读了有关聚合的创建和职责的信息，并且对如何正确实施它们有疑问。假设我们有2个实体内的上下文。一个是公司，第二个是用户。业务规则在公司实体中，这意味着它应该成为聚合根。对于公司，我们只能分配3个用户，而当Comapny的状态为“已阻止”时，我们不能分配用户。用户也可以使用emial和密码登录。考虑到这一点，对User实体的每项操作都应通过Aggregate根进行调用，并且User不应拥有自己的存储库。如果没有公司根目录我们无法直接对用户执行登录操作，该如何对用户进行登录？我们不能从总体上称呼用户。如何找到具有提供的电子邮件和密码的用户？获取所有聚合并遍历其用户效率低下，我认为这不是一个好主意。 谢谢你的帮助。
答案 0 :(得分：3)
我认为用户应该属于另一个BC（负责管理身份验证和授权）。在公司BC中，您必须从身份验证和授权BC中获取用户。您必须将两个BC与上下文映射模式集成在一起，其中身份验证和授权BC在上游，而公司BC在下游。
答案 1 :(得分：2)
身份验证通常不是域的一部分（在所有用例的99％中），而只是基础结构的一部分。
因此，Users永远不会出现在有界上下文中。在真实的商业世界中，既没有用户，也没有人，只有人，人，员工，经理或联系人等。
因此，对于日志记录问题，您需要我们的用户使用用户名+密码进行身份验证。这些用户具有ID（数字，字符串或guid）。
您的Employee或Persons实体/集合（或您命名的名称取决于您的域，确切的术语取决于公司之间的关系-普遍使用的语言）然后仅包含属于给该人（但不提供与身份相关的信息）。
然后您可以将员工连接到用户（通过将employee id作为用于登录的用户的ID，一个额外字段或通过1：1或1：n查找表来实现。
这样，您可以轻松删除用户（登录名）而不删除Employee实体，因为在现实情况下，您不能轻松地仅删除业务数据（即，假设删除用户会删除每个用户的收件人）发票或CRM数据，没有人会知道此人过去曾在此工作过）。