假设我有一个带有2个聚合根的"目录"有界上下文.公司和个人.公司拥有一组子实体"位置",用于保存人员聚合的ID以及一些额外的值数据.
都好.
现在我们去添加一个带有聚合根JobAriticle的"Article"有界上下文.这需要一个从公司位置映射的Contact值对象.
所以知道你应该只引用聚合根,我该怎么办？假设公司与位置关系存在不变量,因此我不想拆分聚合.是否可以通过反腐败层使用公司和位置ID映射位置？或者我是否需要尝试拆分公司聚合.
我一直在阅读 Eric Evans 的 DDD: Tackling Complexity in the Heart of the Software 和上下文映射部分，Evans 引用了一个使用翻译器将它们集成的 2 个有界上下文（预订上下文和网络遍历服务）的示例。
如果我理解正确的话，当我们创建模型时，我们会将所有内容放入有界上下文中，为域创建概念边界。我的问题是：
如果一切都应该在一个有界上下文中，那么翻译器应该位于哪里？在 Evans 的示例图中，翻译器位于两个有界上下文之外（介于两者之间）。
假设我们有一个团队在处理 ERP。ERP 应该放在几个有界上下文中还是只放在一个有界上下文中。根据 Evans 的样本，设计了有界上下文，以便多个团队可以在自己的模型上工作。但既然这是一个团队，他们会不会受益于单一模型，因此集成不会成为问题？还是我理解错了？
在问题 2 的情况下，如果有多个有界上下文，如果在实现中，我们需要一个来自 Accounting 的类在 Payroll 中使用怎么办？我认为我们在这里不需要翻译，但我不确定如何分享所需的课程。仅从另一个有界上下文中引用所需的类就可以了吗？
最后，DDD 中的模块如何与有界上下文相关？
恕我直言,最出色的DDD概念之一是应用程序中单独的上下文的能力.但我对如何将所有东西放在一起工作感到困惑.
首先,我知道有一件事与其他事无关.但我的问题完全在于Infrastructure/ORM部分.
例如,我有一个名为Procedure(医疗程序)的域对象.在注册的上下文中,唯一重要的是代码和名称.但是在程序管理上下文中,我有很多其他领域,比如Price,属于这个特定的上下文.
如何使用EF Code First在具有不同属性的两个具有相同名称(在不同上下文中)的实体？基本上,我想在同一个表中保存所有字段,但在一个上下文中只检索2个字段,在另一个上下文中检索所有字段.我怎么能做到这一点？
.net domain-driven-design entity-framework ef-code-first bounded-contexts
我正在努力理解使用Doctrine 2在来自不同有界上下文的两个实体之间实现关联映射的正确方法。假设有两个分别属于“ User”和“ Content”有界上下文的“ User”和“ Post”实体。在“内容”上下文中还有一个“用户”概念，它通过多对一关联来确定“帖子”的作者。因此，“内容”上下文中的“用户”只是一个包含用户ID的值对象。
我的问题是我应该如何使用教义2实现这种关联？我有两个解决方案，都有各自的问题：
解决方案1：
/**
* @ORM\Entity
* @ORM\Table(name="posts")
* @ORM\HasLifecycleCallbacks()
*/
class Post
{
...
/**
* @ORM\ManyToOne(targetEntity="UserBC\User", inversedBy="posts")
* @ORM\JoinColumn(name="user_id", referencedColumnName="id")
*/
private $user;
...
}
解决方案2：
/**
* @ORM\Entity
* @ORM\Table(name="posts")
* @ORM\HasLifecycleCallbacks()
*/
class Post
{
...
/**
* @ORM\Column(type="integer")
*/
private $user_id;
...
}
在第一个解决方案中，“用户”上下文中的“用户”实体已在“内容”上下文中使用，这违反了彼此独立的BC上的DDD规则。第二种解决方案遵循DDD规则，但会影响数据库架构（通过外键约束删除“用户”和“帖子”表之间的数据库级关系）。
那么，实现这种关联的正确方法是什么？
我目前正在阅读有关DDD的内容,但我无法找到这个问题的答案.如果我们有一个包含多个有界上下文的大型应用程序,那么据我所知,我们应该实现每个BC,因为它是一个单独的应用程序.因此,可以得出结论,每个BC都有自己的UI和事件存储.我之前认为我们只有一个事件存储器,因为根据一些文章(关于CQRS)它是单一的事实来源.这些陈述的唯一问题是他们缺乏背景.那么事件是在单个有界上下文中还是在整个应用程序中存储单一事实来源？
我观看了Julie Lerman关于在企业应用程序中使用EF的视频.现在我正在开发一个使用"Bounded Contexts"的网站以及她在该系列中教过的其他内容.
问题是我不知道如何在我的"业务层"中使用有界上下文(BC).为了更清楚:BL应该如何知道它应该使用哪个特定的BC.
假设UI从业务层请求产品列表.在BL我有一个返回产品列表的方法:GetAll().此方法不知道UI的哪个部分(站点管理员,主持人或公共用户)已请求产品列表.由于每个用户/场景都有自己的有界上下文,因此需要使用该相关上下文来提取列表.BL如何选择合适的BC？
此外,我不希望UI层与数据层交互.
如何才能做到这一点？
domain-driven-design entity-framework n-tier-architecture bounded-contexts
在有界上下文中可以有许多这样的聚合根吗
Product
ProductID : GUID
Name : string
Price : float
ProductPromotion
ProductID : GUID
Discounted : float
ProductShortName
ProductID : GUID
ShortName : string
我不知道它会打破有界上下文的规则，虽然这些是不同类型的产品但在上下文中。
我刚开始学习 DDD 概念，但我无法理解一些东西。
1-上下文映射与有界上下文和子域有什么区别？
2-如何识别限界上下文之间的关系？
多少个聚合应该有一个有界上下文？
我之所以问这个问题，是因为书籍和其他资源中的信息过于广泛/抽象。
我想，这取决于某些域模型及其结构。有多少个有界上下文有一个域模型？每个有界上下文中有多少实体。我想，所有这些问题都依赖于这个事实，即在单个有界上下文中应该有多少聚合。
此外，如果回忆一下 SOLID 原则和拥有松散耦合的小代码段的共同想法。我想，每个有界上下文最多可以有 3-4 个聚合。如果单个有界上下文中有更多聚合，则软件设计可能存在一些问题。
我现在正在阅读 Vernon 的关于 DDD 的书，但是很难理解如何设计这些东西。
有界上下文名称应该是复数还是单数，为什么？例如，如果我有汽车租赁网站，我应该有经销商限制上下文还是经销商？