这有什么意义？
简短的回答：不会。
更长的答案：用于开发域模型的重量级模式不适用于解决方案中仅是数据库的那些部分。
乌迪·达汉（Udi Dahan）有一个有趣的发现，可能有助于澄清这一点
Dahan认为服务必须同时具有某种功能和某些数据。如果它没有数据，那么它只是一个函数。如果它所做的只是对数据执行CRUD操作，那么它就是数据库。
毕竟，域模型的目的是确保对数据的所有更新都保持当前业务不变。或者，换句话说，域模型负责确保充当记录系统的数据库是正确的。
当您使用CRUD系统时，通常不是数据记录系统。在现实世界中是记录的书，你的数据库仅仅是一个现实世界中的本地缓存表示。
例如，出现在用户个人资料中的大多数信息（例如电子邮件地址或政府颁发的标识号）都有不属于您的业务的真相来源-由他人的邮件管理员分配和撤消电子邮件地址，而不是您的应用。分配SSN的是政府，而不是您的应用。
因此，您通常不会对来自外界的数据进行任何域验证。您可能已经进行了检查以确保数据格式正确并进行了适当的清理 ; 但它不是您的数据-您的域模型没有否决权。
在使用层的DDD方法中，CRUD操作似乎遍历域层。但至少在我们看来，这似乎没有道理。
对于数据库是记录簿的情况，这是正确的。
瓦尔扎（Ouarzy）这样说。
但是，在处理大量遗留代码时，我发现了常见错误，无法识别域内部和外部。
仅当数据模型周围没有业务逻辑时，才可以将应用程序视为CRUD。即使在这种（罕见）情况下，您的数据模型也不是域模型。这只是意味着，由于不涉及业务逻辑，因此我们不需要任何抽象来管理它，因此我们没有域模型。
我们使用域模型来管理域内的数据。来自域外的数据已经在其他地方进行了管理-我们只是在缓存一个副本。
格雷格·扬（Greg Young）使用仓库系统作为解决方案的主要例证，其中记录册位于其他地方（即：仓库地面）。他描述的实现与您非常相似-一个逻辑数据库来捕获从仓库收到的消息，然后是一个单独的逻辑数据库来缓存对这些消息的分析得出的结论。
因此，也许我们在这里有两个有限的上下文？每个都有一个不同的模型investment account
也许。我不愿意将其标记为有限的上下文，因为尚不清楚还会带来什么其他行李。可能是您有两个上下文，也可能是一个上下文，您尚未熟悉的普遍语言中有细微的差异。
可能的试金石测试：您需要多少位领域专家才能涵盖此范围，或者仅一位以不同方式讨论组件。基本上，您可以通过反向处理康韦定律来猜测您拥有多少有界上下文。
如果您认为有界上下文与服务保持一致，则可能会更容易：您是否应该能够独立部署这两项功能？是的，表明了两个有限的上下文；但是如果需要保持同步，那么也许只是其中之一。
