我真的是 DDD 的新手，并试图掌握一些概念。
谁能解释一下 DDD 中的领域建模背后的想法。
我已经浏览了维基百科的解释：http://en.wikipedia.org/wiki/Domain_model，但我的理解似乎仍然存在一些灰色地带。
根据我的理解，领域建模涉及围绕业务实体构建模型以表达它们的关系，表达参与模型的实体等。
这不是一直在实践吗？在面向对象的世界中，您将业务实体建模为类、对象等，然后围绕此构建软件。
我不明白领域建模在 DDD 中的重点。它与您在 OO 世界中找到的对象/类建模相同，还是对 DDD 来说是新事物？ 它与面向对象的设计/建模有何不同？
我们非常感谢您的回答。
【问题讨论】：
一个区别是 DDD 中 Domain Model Pattern 的“正确”实现与横切关注点隔离。
例如，它包含与数据库或其他持久性无关的内容。包含验证逻辑的地方，是业务验证，而不是“名称是否超过列长？”验证。
这个想法是领域模型封装了“业务”——用业务术语（“普遍存在的语言”），尽可能地——并在不默认需求的情况下将业务的相关方面暴露给“程序”软件。
另一方面，“软件”关注 IO、UI 等，但将所有业务逻辑委托给领域模型。
原则上，您可以将域模型封装在一个程序集中并在多个应用程序中使用它。当业务规则发生变化时，正如它们所做的那样，您有一个非常合乎逻辑的位置来影响变化（因为该模型是业务相关方面的 1:1 或几乎如此的表示，并且以与业务）。
【讨论】：
DDD 中的 Domain 不需要在 OO 中实现。以我的经验，OO 域模型通常是最好的，但也有一些非常有效的例子表明它可能不是。
您可以使用规则引擎在规则中实现域（例如，在荷兰，大型抵押贷款申请就是这样做的）。或者你可以用函数式语言来做。本质是，您的域，无论以何种方式实现，都与我通常所说的应用程序的技术方面（或者，正如前面的答案所说的那样，横切关注点，尽管我认为很可能存在领域内的横切关注点）。可以使用适配器实现的隔离层使域尽可能地，甚至完全独立于技术细节。该层通常利用 Facade 和 Observer 等模式。
【讨论】：