每当我阅读有关MVVM或DDD之类的现代设计模式的文章时，都很难将示例转换为我通常正在研究的领域。
所有这些模式得出的结论是，领域模型应该存在于它们自己的小气泡中，没有任何引用，不应暴露于绑定(bind) View ，应该是POCO/POJO并包含“业务逻辑”。
我总是问自己一个问题:领域模型应该怎么做？
答案显然是“处理业务逻辑”，但是当我考虑可能是什么时，我很难找到真实的例子。
例如:一个经常出现的典型示例是金融应用程序，其中您可以拥有一个BankAccount实体，该实体可以具有TransferMoneyTo(otherAccount)函数。
从理论上讲，这听起来不错，但是在现实世界中，此应用程序将无法管理世界上所有的银行帐户，而只能管理一个银行的帐户。
因此，现实世界中的应用程序将必须以某种方式联系另一家银行的服务器以发起此交易。显然，此“某种程度上”是服务，不允许BankAccount对其进行引用。这意味着对于隔离域模型而言，这不是一个很好的例子。
到目前为止，我已经阅读了所有示例，这些示例都忽略了重要的细节或琐碎的事情，无论是这样的示例，还是仅在示例中有效的示例。我的意思是，“业务逻辑”仅由简单的验证(例如必填字段)组成。
所有这些导致anemic domain model(也许除了验证之外)，这应该是一件坏事。
我的问题是:除了验证之外，术语“业务逻辑” 背后隐藏着什么，这证明有必要使用单独的域模型？
注意:我知道这取决于您正在使用的域，但是我认为至少应该有一些DDD实际上有用的示例。
最佳答案
许多域模型反射(reflect)了业务流程，因此包含状态机，您可以在其中根据某些规则将事物从已知的有效状态转换为另一有效状态。您几乎在每项业务中都会得到这种过程。其他领域可能涉及更复杂的内部算法和数据转换。
除非您将铁路公司的座位预定系统或政府的税收计算过程视为“验证”，否则这些几乎不属于简单的“公正验证”类别。
对于与外界进行通信的领域，这并不是他们的真正责任。通常，您拥有的是发出事件的域，该事件说“这件事发生了!”。应用上下文会对其进行处理并启动与外部系统的适当通信。
协调对内部和外部子系统的调用，以便数据流入，流出和通过应用程序不是域逻辑，这是技术级应用程序的关注点。以一种或另一种形式(事件，DI等)进行的控制反转通常是使域不知道这一点的关键。
关于mvvm - 域模型和 “Business Logic”混淆，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/29558014/