富vs贫血域模型

Question 1

我正在决定是否应该在贫血域模型上使用富域模型，并寻找两者的良好示例。

我一直在使用Anemic域模型构建Web应用程序，并以Service- >存储库-> Storage Layer系统为后盾，使用FluentValidation进行BL验证，并将我所有的BL都放入Service层。

我读过Eric Evan的DDD书，他（以及Fowler等人）似乎认为Anemic Domain Models是一种反模式。

所以我只是真的想对这个问题有一些了解。

另外，我确实在寻找Rich Domain模型的一些好（基本）示例，以及它提供的Anemic Domain Model带来的好处。

Question 2

区别在于，贫血模型将逻辑与数据分开。该逻辑通常放在名为类**Service，**Util，**Manager，**Helper等。这些类实现了数据解释逻辑，因此将数据模型作为参数。例如

public BigDecimal calculateTotal(Order order){
...
}

而富域方法则通过将数据解释逻辑放入富域模型来逆转这种情况。因此，它将逻辑和数据放在一起，一个丰富的域模型将如下所示：

order.getTotal();

这对对象一致性有很大影响。由于数据解释逻辑包装了数据（只能通过对象方法访问数据），因此这些方法可以对其他数据的状态变化做出反应->这就是我们所说的行为。

在贫血症模型中，数据模型不能保证它们处于合法状态，而在富域模型中则可以保证。富域模型应用了OO原理，例如封装，信息隐藏以及将数据和逻辑组合在一起，因此从OO角度来看，贫血模型是一种反模式。

要获得更深入的了解，请查看我的博客https://www.link-intersystems.com/blog/2011/10/01/anemic-vs-rich-domain-models/

Question 3

Bozhidar Bozhanov在此博客文章中似乎主张贫血模型。

这是他介绍的摘要：

域对象不应由Spring（IoC）管理，它们不应具有DAO或与之相关的任何基础架构
域对象具有由休眠（或持久性机制）设置的它们依赖的域对象
域对象执行业务逻辑，就像DDD的核心思想一样，但这不包括数据库查询或CRUD –仅对对象内部状态进行的操作
几乎不需要DTO-在大多数情况下，域对象本身就是DTO（这节省了一些样板代码）
服务执行CRUD操作，发送电子邮件，协调域对象，基于多个域对象生成报告，执行查询等。
服务（应用程序）层并不薄，但不包括域对象固有的业务规则
应避免生成代码。应该使用抽象，设计模式和DI来克服代码生成的需求，并最终–摆脱代码重复。

更新

我最近读了这篇文章，在那儿，作者提倡采用一种混合方法-领域对象可以仅根据状态来回答各种问题（在完全贫乏的模型中，这可以在服务层完成）

Question 4

我的观点是：

贫血症域模型=映射到对象的数据库表（仅字段值，无实际行为）

富域模型=暴露行为的对象的集合

如果您想创建一个简单的CRUD应用程序，那么具有经典MVC框架的贫血模型就足够了。但是，如果您想实现某种逻辑，贫血模型意味着您将不会进行面向对象的编程。

*请注意，对象行为与持久性无关。不同的层（数据映射器，存储库等）负责持久化域对象。

Question 5

首先，我复制粘贴了这篇文章的答案 http://msdn.microsoft.com/en-gb/magazine/dn385704.aspx

图1显示了一个贫血域模型，它基本上是一个具有getter和setter的架构。

Figure 1 Typical Anemic Domain Model Classes Look Like Database Tables

public class Customer : Person
{
  public Customer()
  {
    Orders = new List<Order>();
  }
  public ICollection<Order> Orders { get; set; }
  public string SalesPersonId { get; set; }
  public ShippingAddress ShippingAddress { get; set; }
}
public abstract class Person
{
  public int Id { get; set; }
  public string Title { get; set; }
  public string FirstName { get; set; }
  public string LastName { get; set; }
  public string CompanyName { get; set; }
  public string EmailAddress { get; set; }
  public string Phone { get; set; }
}

在这个更丰富的模型中，Customer的公共表面由显式方法组成，而不是简单地公开要读取和写入的属性。

Figure 2 A Customer Type That’s a Rich Domain Model, Not Simply Properties

public class Customer : Contact
{
  public Customer(string firstName, string lastName, string email)
  {
    FullName = new FullName(firstName, lastName);
    EmailAddress = email;
    Status = CustomerStatus.Silver;
  }
  internal Customer()
  {
  }
  public void UseBillingAddressForShippingAddress()
  {
    ShippingAddress = new Address(
      BillingAddress.Street1, BillingAddress.Street2,
      BillingAddress.City, BillingAddress.Region,
      BillingAddress.Country, BillingAddress.PostalCode);
  }
  public void CreateNewShippingAddress(string street1, string street2,
   string city, string region, string country, string postalCode)
  {
    ShippingAddress = new Address(
      street1,street2,
      city,region,
      country,postalCode)
  }
  public void CreateBillingInformation(string street1,string street2,
   string city,string region,string country, string postalCode,
   string creditcardNumber, string bankName)
  {
    BillingAddress = new Address      (street1,street2, city,region,country,postalCode );
    CreditCard = new CustomerCreditCard (bankName, creditcardNumber );
  }
  public void SetCustomerContactDetails
   (string email, string phone, string companyName)
  {
    EmailAddress = email;
    Phone = phone;
    CompanyName = companyName;
  }
  public string SalesPersonId { get; private set; }
  public CustomerStatus Status { get; private set; }
  public Address ShippingAddress { get; private set; }
  public Address BillingAddress { get; private set; }
  public CustomerCreditCard CreditCard { get; private set; }
}

Question 6

富域类的好处之一是，只要您在任何层中都有对对象的引用，就可以调用它们的行为（方法）。另外，您倾向于编写小型的分布式方法，这些方法可以协同工作。在贫血症领域类中，您倾向于编写通常由用例驱动的胖过程方法（在服务层中）。与丰富的域类相比，它们通常较难维护。

具有行为的域类的示例：

class Order {

     String number

     List<OrderItem> items

     ItemList bonus

     Delivery delivery

     void addItem(Item item) { // add bonus if necessary }

     ItemList needToDeliver() { // items + bonus }

     void deliver() {
         delivery = new Delivery()
         delivery.items = needToDeliver()
     }

}

方法needToDeliver()将返回需要交付的物品清单，包括奖金。可以在类内部，另一个相关类或另一个层中调用它。例如，如果您通过Order查看，则可以使用needToDeliver()selected Order来显示要由用户确认的项目列表，然后用户单击保存按钮以保留Order。

回应评论

这是我从控制器使用域类的方式：

def save = {
   Order order = new Order()
   order.addItem(new Item())
   order.addItem(new Item())
   repository.create(order)
}

的创建Order及其LineItem在一个交易。如果LineItem无法创建其中之一，则不会Order创建。

我倾向于使用表示单个事务的方法，例如：

def deliver = {
   Order order = repository.findOrderByNumber('ORDER-1')
   order.deliver()       
   // save order if necessary
}

内部的任何内容deliver()都将作为一个事务执行。如果需要在单个事务中执行许多不相关的方法，则可以创建一个服务类。

为了避免延迟加载异常，我使用了JPA 2.1命名实体图。例如，在交付屏幕的控制器中，我可以创建方法来加载delivery属性和忽略属性bonus，例如repository.findOrderByNumberFetchDelivery()。在奖金屏幕中，我调用了另一个加载bonus属性并忽略的方法delivery，例如repository.findOrderByNumberFetchBonus()。这需要纪律，因为我仍然无法deliver()在奖金屏幕内致电。

Question 7

当我过去编写整体桌面应用程序时，我建立了丰富的域模型，并乐于构建它们。

现在，我编写了微小的HTTP微服务，其中包含的代码很少，包括贫乏的DTO。

我认为DDD和这种贫乏的争论可以追溯到整体式桌面或服务器应用程序时代。我记得那个时代，我同意贫血模型是奇怪的。我构建了一个大型的整体外汇交易应用程序，但没有模型，真的，这太可怕了。

对于微服务而言，具有丰富行为的小型服务可以说是域内可组合的模型和集合。因此，微服务实现本身可能不需要进一步的DDD。微服务应用程序可以是域。

订单微服务可能只有很少的功能，以RESTful资源或通过SOAP或其他方式表示。订单微服务代码可能非常简单。

更大，更单一的单一（微）服务，尤其是将其保持在RAM中的模型，可能会受益于DDD。

Question 8

我认为问题的根源在于错误的二分法。如何提取这两个模型：丰富模型和“贫血”模型并进行对比？我认为，只有当您对什么是类有错误的想法时，才有可能。我不确定，但我想我是在Youtube的Bozhidar Bozhanov视频之一中找到的。一个类不是数据+方法的数据。完全无效的理解导致将类划分为两类：仅数据，因此贫乏模型和数据+方法 -如此丰富的模型（更准确地说，存在第三类：仅方法）。

的确，类是某些本体模型中的一个概念，一个单词，一个定义，一个术语，一个想法，它是DENOTAT。这种理解消除了错误的二分法：您不能只有贫血模型或富人模型，因为这意味着您的模型不够用，与现实不相关：某些概念仅包含数据，某些概念仅包含方法，有些他们混合在一起。因为在这种情况下，我们试图描述一些类别，对象集，关系，带有类的概念，并且我们知道，一些概念仅是过程（方法），一些仅是属性集（数据），一些它们是与属性的关系（混合）。

我认为适当的应用程序应包括各种类，并避免狂热地自我限制为仅一个模型。无论如何，逻辑是如何表示的：无论如何使用代码或可解释的数据对象（如Free Monads）：我们应该具有表示流程，逻辑，关系，属性，特征，数据等的类（概念，符号），而不是设法避免其中一些或将它们全部减少为一种。

因此，我们可以将逻辑提取到另一类并将数据保留在原始类中，但是这是没有意义的，因为某些概念可以包含属性和关系/过程/方法，并且将它们分开将在2个名称下重复该概念简化为模式：“对象属性”和“对象逻辑”。由于它们的局限性，它在过程语言和功能语言中很好用，但是对于一种允许您描述各种概念的语言来说，它过于自我约束。

Question 9

流量域模型对于ORM和在网络上的轻松传输（所有商业应用程序的命脉）很重要，但是OO对于封装和简化代码的“事务/处理”部分非常重要。

因此，重要的是能够识别一个世界并将其从另一个世界转化。

为Anemic模型命名，例如AnemicUser或UserDAO等，以便开发人员知道可以使用更好的类，然后为无Anemic类提供适当的构造函数

User(AnemicUser au)

和适配器方法来创建贫血类以进行运输/持久性

User::ToAnemicUser()

旨在在传输/持久性之外的任何地方使用无贫民用户

Question 10

以下示例可能会有所帮助：

贫血

class Box
{
    public int Height { get; set; }
    public int Width { get; set; }
}

非贫血

class Box
{
    public int Height { get; private set; }
    public int Width { get; private set; }

    public Box(int height, int width)
    {
        if (height <= 0) {
            throw new ArgumentOutOfRangeException(nameof(height));
        }
        if (width <= 0) {
            throw new ArgumentOutOfRangeException(nameof(width));
        }
        Height = height;
        Width = width;
    }

    public int area()
    {
       return Height * Width;
    }
}

Question 11

DDD的经典方法并未说明要不惜一切代价避免Anemic与Rich模型。但是，MDA仍可以应用所有DDD概念（有界上下文，上下文映射，值对象等），但在所有情况下都使用Anemic与Rich模型。在许多情况下，使用域服务在一组域聚合中协调复杂的域用例比从应用程序层调用聚合要好得多。与经典DDD方法的唯一区别是所有验证和业务规则都存放在哪里？有一个称为模型验证器的新构造。验证程序可确保在发生任何用例或域工作流之前，完整输入模型的完整性。根和子实体的总和是贫乏的，但每个实体都可以根据需要调用自己的模型验证器，通过它的根验证器。验证器仍然遵守SRP，易于维护并且可以进行单元测试。

发生这种转变的原因是，我们现在正朝着微服务的API优先而非UX优先的方向发展。REST在其中扮演了非常重要的角色。传统的API方法（由于SOAP）最初固定在基于命令的API与HTTP动词（POST，PUT，PATCH，GET和DELETE）上。基于命令的API非常适合Rich Model面向对象的方法，并且仍然非常有效。但是，尽管基于CRUD的简单API可以放入Rich模型中，但更适合与简单的贫血模型，验证器和域服务来协调其余部分。

我喜欢DDD所提供的所有功能，但是有时候您需要对其进行扩展以适应不断变化的更好的体系结构。