域驱动设计对于不是那么复杂的域有用/有用吗？

在评估工作中的潜在项目时，我建议对它的对象模型使用领域驱动的设计方法可能会更有利。该项目没有一个过于复杂的领域，所以我的同事把这个扔给了我：

有人说，DDD在存在复杂域模型的情况下是有利的（“ ...只要我们在复杂，复杂域中运行，都适用” Eric Evans）。

我所迷惑的是-您如何定义域的复杂性？是否可以通过域模型中聚合根的数量来定义？对象交互中的域是否复杂？

我们正在评估的领域与在线发布和内容管理相关。

最重要的因素是业务逻辑的复杂性，或者称为应用程序行为。第二个最重要的因素是技术问题和用于描述该问题的业务词汇之间存在多少差距，因为DDD是要在业务和工程团队之间创建共享词汇。

DDD中使用的某些模式通常在企业应用程序体系结构中很有用，例如存储库模式，绑定上下文和分层体系结构。仅仅因为您正在使用这些模式，并不意味着您在进行域驱动设计。

如果没有太多行为，也就是说，您主要是在存储数据，而不是对这些数据进行操作，则在构建该域层时价值可能会大大降低。在内容管理中，如果您要做的只是批准和发布，那么可以由系统中的标志而不是域方法来表示。但是，当您开始添加其他行为时，完整域层的适当性就变得更加明显。

如果我们在谈论内容管理，那么以下一些（想象的）规则可能会开始暗示对DDD的需求：

• 如果故事在xx / yy / zz日期之前一直被禁运，则将其发布以打印，然后发布至网络；如果没有禁运，请发布到网络上并进行打印
• 立即将这个故事提供给付费用户；2周后向公众发布。
• 编写故事后，将其发送给编辑器以进行修订，校对和批准。批准后，将其发送到生产环境。如果由于空间原因而使故事停滞不前，请在线提供扩展版本。