这只是一个例子。
假设您有 2 个实体用于 2 个不同的上下文边界。第一个上下文是 SkillContexter，实体是“Player”，具有 3 个属性：Id、Name 和 SkillLevel。在另一个上下文（Contactcontext）中，实体是“玩家”并具有 3 个属性：Id、Name 和 EMail。
如何将这些实体保存到数据库中？我只想要一张桌子（玩家）而不是两张桌子（PlayerContact，PlayerSkill）。我应该为玩家提供两个不同的存储库，将不同的上下文实体保存到同一张表中吗？或者我应该有一个“主”玩家实体来保存我需要保存的所有属性，以便我创建一个名为 PlayerMaster 的新实体，它有 4 个属性：Id、Name、EMail 和 SkillLevel？
第一个解决方案为我提供了更多存储库，第二个解决方案让我创建了一个“技术”实体，其唯一目的是将数据保存到数据库中，这感觉真的不对，或者有没有更好的解决方案我错过了？
你们是怎么解决的？
【问题讨论】：
当我第一次开始使用 DDD 时，我也与上下文 + 域 + 模块 + 模型的事物组织作斗争。
DDD 的真正目的是作为构建领域模型的指南。一旦我停止尝试对上下文和边界进行子组织，并开始思考实体之间真正共享的内容 - 事情就开始更好地融合在一起。
我实际上不使用上下文，除非它是一个完全不同的应用程序（app = context）。只是我的偏好。但是，我确实有只共享代码中通用的基本抽象和接口的模块（IRepository、IComponent 等）。问题是，DDD 说模块可以在模块之间共享实体——但是，只能在非常有限的范围内（你真的不想经常这样做）。
考虑到这一点，我将摆脱使用上下文并转向“我真正想要完成什么，这些模型有什么共同点）。这就是我的想法，阅读你的问题（如果我理解他们）。
Person() is a base entity. It has ID and Name.
PlayerSkill() is a Value Object, that is
accessable from Person().PlayerSkill.
Contact() is an entity that inherits Person(),
so it inherits ID and Name, and has additional Contact properties you want.
现在，我刚刚撕毁了您的域名。我知道。
您也可以使用混合方法：
Person() is a base entity. It has ID and Name.
Player() inherits Person(), applies Skill()
and other VOs.
Contact() inherits Person(), applies Address()
and other VOs.
【讨论】：
我不太清楚你所说的上下文边界是什么意思，所以我的答案可能是错误的。
两个玩家实体是否代表同一个物理实体（人）？如果是这样，那么我将创建一个具有所有四个属性的单个 Player 实体并将它们的数据存储在一个表中。
【讨论】：