Domain driven design 领域驱动设计挑战-实体属于哪个领域？

我正在分析一个相当不错的企业资源规划软件，因为ERP涵盖了从会计到销售和CRM的许多领域，所以我选择使用领域驱动设计。现在我有两个问题：

启动DDD的主要应用（非理论）资源是什么

例如，如何确定“发票”指向哪个域或模块 属于？它属于“会计”还是“销售”

可能有很多这样的例子，在分离实体和域时我会感到困惑

---

我怎样才能克服这个问题呢？

我不是DDD的权威，但这是我的2美分

1） 你读过《蓝色圣经》吗？这里的示例取自Eric Evans构建真实航运平台的经验。我还没有看到任何其他出版的例子像书中的那样大

2） 发票可以同时属于这两个领域，但它在每个领域可能意味着不同的东西，在销售中它将链接到订单、付款等；在会计中，它将链接到分类账和账户。 你不会找到一个独特的领域来解决整个ERP问题。我没有ERP方面的经验，但了解销售和CRM，我会说你可能会发现15多个不同的领域，有些是微型框架，有些是解决问题的大块部分

关于你的困惑：我过去所做的是在SO中找到与DDD相关的问题（有些问题确实很有启发性），并阅读那些对DDD非常了解的人的博客帖子——有很多关于DDD的好博客帖子

我建议在实践中使用DDD有两种资源：第一种是唯一一本著名的书，另一种是，但它们都假设您首先读过Eric Evan的书

我认为没有人有资格很好地回答第二个问题，大多数人会说这取决于上下文和特定的应用程序。硬道理是DDD是关于设计的，它需要复杂的技能（这并不容易）。因此，我建议您使用支持测试以增量方式开发代码，以便在适当的时候更改设计（eric称之为突破） 对你来说可能是一个很好的资源。