【发布时间】：2013-05-11 22:10:04
【问题描述】：
我希望拥有一个或多个可重用类库，这些库基本上是值对象，例如 Address、PhoneNumber、EmailAdress，主要包含属性和一些支持方法。我的领域层如何在不违反领域层不应包含外部引用的规则的情况下使用这些，并且不将它们定义为领域层中的接口/抽象类？
【问题讨论】：
标签： domain-driven-design value-objects
【发布时间】：2013-05-11 22:10:04
【问题描述】：
...不违反域层不应包含外部引用的规则
我认为您对“外部参考”的定义需要重新评估。很难想象一个不引用任何东西的领域层。在 C# 和 Java 中，您将至少引用基本的数字类型、日期和字符串。我也认为引用 Noda/Joda time 等外部库没有任何害处。另一方面，您当然不想引用任何繁重的技术库，例如持久性、通信、UI 等。
所以我想说您可以构建自己的从域引用的可重用库，但这需要非常仔细的考虑，并且通常不值得它创建的耦合。我会为每种类型使用以下标准：
- 应该与上下文无关。例如，EmailAddress 相对独立于使用它的上下文。另一方面，地址可能具有不同的含义，具体取决于有界上下文。
- 应该是稳定的（不经常改变）。
- 不应隐藏任何进程外通信（数据库、网络等）
- 不应有任何自己的依赖项（标准 Java/C# 除外）
【讨论】：
-
1+ 表示第一个要点。我已经看到很多次为了重用而脱离上下文使用实体。这也与您的第二个要点有关，因为在 n 上下文中使用实体会给它 n 更改的理由，并且可能意味着它将更改 n 多次。
我认为您所指的是共享内核。
共享内核——这是两个团队共享部分内核的地方 域模型。这不应该在没有其他团队的情况下改变 咨询过。
虽然这看起来不错，但由于我们习惯于不重复自己，请注意其中的陷阱：
- 这些概念在每种情况下都应具有相同的含义。其中一些概念根据上下文存在细微差别。咨询您的领域专家。
- 更改成本更高；复制这几个类以便您自己更改它们可能比在发生变化时咨询多个团队更便宜。
【讨论】：
-
我认为其中一些可能是抽象类，客户域可以在其中添加自定义上下文。
-
您也可以使用包含来添加语义，而不是继承。 Java 和 C# 不允许多重继承，因此有时包含是您唯一的选择。包含允许您重新定义接口以匹配不同域的需求。
稳定性是双向的。如果您将一个实体拉出到每个域中，那么任何更改都必须跨多个项目执行。如果您不这样做，则必须在多个域之间协调更改。前者的后勤工作比后者容易，但后者涉及的工作量可能更大。无论哪种方式，您都必须在每个平台上测试更改。
除非实体成熟并具有相对明确定义的语义，否则我的经验是几乎所有内容都会发生变化。所以稳定性很好，但可能有点红鲱鱼。
话虽如此，我喜欢（和 +1）@Dmitry。
【讨论】：