共享内核描述了两个有界上下文之间的关系。我还没有找到任何有用的信息，如何有效地处理多个有界上下文之间的共享对象。
我们使用值对象而不是基本类型。实体id也是作为值对象类型和实现的。所以有类型像ProductId, ServiceId, OrderId, PersonId, ClothingSize, ServiceComment, MusicStyle, danceyle, FoodRestrictions, Money，还有很多很多。
我正在努力如何实现这些共享对象。如果只考虑两个有界的上下文，它就很简单了。共享内核可以包含在两个上下文中使用的对象。
如果有许多有界上下文，并且在每对上下文之间使用一个单独的共享内核，则共享内核的数量将以n*(n-1)爆炸。在多个上下文中使用的值对象将再次被复制，共享上下文将失去其优势。
每个值对象还需要EF Core和资源文件的值转换器，用于转换字段名和错误消息。
一个解决方案是使用一个大的共享内核． 在至少两个有界上下文中使用的所有对象都在这里结束。缺点是，如果添加了一个新的有界上下文，该上下文使用了另一个上下文没有使用过的值对象，则必须将其移动到共享内核(如果不再共享，可能会再次删除)。例如，我们在仓库上下文中有一个服装尺寸值对象，然后在服务合同上下文中需要这个对象，因为艺术家得到了一件节日t恤，而尺寸是在合同中声明的。有技术基类，如for值对象、实体、聚合、错误、结果等，它们在任何上下文中使用，毫无疑问属于基本共享内核。
许多共享值对象不是在所有有界上下文中使用，而是在某些上下文中使用。
我们使用c#和。net Core。我们是一个非常小的团队，使用单一的SQL数据库。根据经验，这对我们的负荷是足够的。未来系统可能会扩展，但预计不需要微服务解决方案，但不能排除。
对于每个不同的层(API、应用程序、领域、基础设施/持久性)，我们使用一个单独的项目。项目之间的依赖关系限制了层之间的访问。
我有的想法，在每个有界的上下文中创建一个共享层． 例如，我将为仓库上下文创建一个共享域层，其中包含其他上下文需要的值对象，因此应该被共享。然后，只有需要这些共享对象的上下文才需要依赖于这个项目。
由于EF Core转换器位于基础设施/持久层，因此我也需要在每个上下文中共享基础设施，但由于这是一个技术方面，我认为所有转换器都进入基础共享内核也是可以的。
这个架构将非常清楚地定义每个上下文中对共享对象的依赖关系。另一方面，这可能会使整个系统过于复杂。我想知道这种额外的复杂性是否有足够的好处，或者如果在所有有界上下文之间只有一个共享内核会更容易。
我现在需要重组代码。这是我的第一个DDD项目，我不想做了很多工作，两周后发现选择的选项不起作用。
成功的项目是如何解决这个问题的?由于我缺乏经验，我想知道我的想法是否被成功地实施了，以及每个解决方案带来了什么问题，这样我就可以针对我们的案例做出明智的决定。
谢谢你的帮助!
对于您所描述的挑战，我的方法是使通用值对象和类型化id成为解决方案"全局语言"的一部分。
为此，我将所有共享值对象和类型化的id部署在单个项目"globalllanguage"中。类似地，共享EF转换器项目。
共享内核的关键不在于有多少项目使用共享内核，而在于认识到你放在那里的任何东西都不再是"有限的"，如果你想改变共享内核中的一个项目，需要根据依赖于它的所有领域的需求进行审查。