DDD符合OOP：如何实现面向对象的存储库？

DDD存储库的典型实现看起来不太像面向对象，例如一种save()方法：

package com.example.domain;

public class Product {  /* public attributes for brevity */
    public String name;
    public Double price;
}

public interface ProductRepo {
    void save(Product product);
} 

基础架构部分：

package com.example.infrastructure;
// imports...

public class JdbcProductRepo implements ProductRepo {
    private JdbcTemplate = ...

    public void save(Product product) {
        JdbcTemplate.update("INSERT INTO product (name, price) VALUES (?, ?)", 
            product.name, product.price);
    }
} 

这样的接口Product至少在使用吸气剂的情况下期望a 是贫血模型。

另一方面，OOP表示Product对象应该知道如何保存自己。

package com.example.domain;

public class Product {
    private String name;
    private Double price;

    void save() {
        // save the product
        // ???
    }
}

关键是，当Product知道如何保存自身时，这意味着基础结构代码不会与域代码分开。

也许我们可以将保存委托给另一个对象：

package com.example.domain;

public class Product {
    private String name;
    private Double price;

    void save(Storage storage) {
        storage
            .with("name", this.name)
            .with("price", this.price)
            .save();
    }
}

public interface Storage {
    Storage with(String name, Object value);
    void save();
}

基础架构部分：

package com.example.infrastructure;
// imports...

public class JdbcProductRepo implements ProductRepo {        
    public void save(Product product) {
        product.save(new JdbcStorage());
    }
}

class JdbcStorage implements Storage {
    private final JdbcTemplate = ...
    private final Map<String, Object> attrs = new HashMap<>();

    private final String tableName;

    public JdbcStorage(String tableName) {
        this.tableName = tableName;
    }

    public Storage with(String name, Object value) {
        attrs.put(name, value);
    }
    public void save() {
        JdbcTemplate.update("INSERT INTO " + tableName + " (name, price) VALUES (?, ?)", 
            attrs.get("name"), attrs.get("price"));
    }
}

实现此目标的最佳方法是什么？是否可以实现面向对象的存储库？

你写了

另一方面，OOP表示Product对象应该知道如何保存自身

并在评论中。

...应对所有使用它的操作负责

这是一个普遍的误解。Product是一个域对象，因此它应该负责涉及单个产品对象的域操作，不少于，也不多，因此绝对不负责所有操作。通常，持久性不被视为域操作。恰恰相反，在企业应用程序中，尝试在域模型中实现持久性无知（至少在一定程度上）并不罕见，为此，将持久性机制保持在单独的存储库类中是一种流行的解决方案。“ DDD”是针对这种应用的技术。

那么对于a来说，明智的域操作是Product什么？这实际上取决于应用程序系统的域上下文。如果系统是小型系统，并且仅专门支持CRUD操作，那么实际上，Product如您的示例中所示，a 可能保持“贫乏”状态。对于此类应用程序，如果值得将数据库操作放在单独的存储库类中或完全使用DDD，则值得商bat。

但是，一旦您的应用程序支持真实的业务操作，例如购买或出售产品，将其保留在库存中并对其进行管理或为它们计算税金，您就开始发现可以合理地归入一Product类的操作，这是很普遍的。例如，CalcTotalPrice(int noOfItems)当考虑批量折扣时，可能会有一个计算n种商品价格的操作。

简而言之，在设计类时，您需要考虑自己的上下文，您在Joel Spolsky的五个世界中所处的世界，并且如果系统包含足够的域逻辑，那么DDD将是有益的。如果答案是肯定的，那么仅由于将持久性机制置于域类之外就不会最终获得贫乏模型。

实践胜过理论。

经验告诉我们Product.Save（）会导致很多问题。为了解决这些问题，我们发明了存储库模式。

确保它违反了隐藏产品数据的OOP规则。但是效果很好。

制定一套涵盖所有内容的一致规则要比制定一些有例外的一般好规则要困难得多。

DDD符合OOP

这有助于记住，这两个想法之间并不存在紧张关系-值对象，集合，存储库是使用的一系列模式，有些人认为这是正确的OOP。

另一方面，OOP表示Product对象应该知道如何保存自己。

不是这样 对象封装自己的数据结构。您在产品中的记忆表示形式负责展示产品行为（无论行为如何）；但是永久性存储位于该存储库（位于存储库之后）上方，并且有自己的工作要做。

确实需要某种方法在数据库的内存表示形式与持久存储的内存之间复制数据。 在边界处，事物趋于变得原始。

从根本上讲，只写数据库并不是特别有用，并且它们在内存中的等效项也没有比“持久”排序有用。Product如果您永远不会将信息带出对象，则将信息放入对象没有任何意义。您不一定会使用“获取器”-您不会尝试共享产品数据结构，当然也不应共享对产品内部表示形式的可变访问。

也许我们可以将保存委托给另一个对象：

那肯定行得通-您的持久性存储有效地成为了回调。我可能会简化界面：

interface ProductStorage {
    onProduct(String name, double price);
}

还有就是要在内存中表示和存储机制之间进行耦合，因为这些信息需要得到从这里到那里（然后再返回）。更改要共享的信息将影响对话的两端。因此，我们最好在可能的地方明确说明这一点。

这种通过回调传递数据的方法在TDD中模拟的开发中发挥了重要作用。

请注意，将信息传递给回调具有与从查询返回信息相同的所有限制-您不应传递数据结构的可变副本。

这种方法与Evans在《蓝皮书》中所描述的有点相反，后者通过查询返回数据是处理问题的常规方法，并且专门设计了域对象以避免混入“持久性问题”。

我确实将DDD理解为一种OOP技术，因此我想完全理解这种看似矛盾的地方。

要记住的一件事-《蓝皮书》是15年前写的，当时Java 1.4在地球上漫游。特别是，这本书早于Java 泛型 -从Evans提出想法开始，到现在我们拥有更多技术。

很好的观察，我完全同意你的看法。这是我关于这个主题的一个话题（仅适用于幻灯片）：面向对象的域驱动设计。

简短的回答：不。您的应用程序中不应存在纯粹是技术性且与域无关的对象。这就像在会计应用程序中实现日志记录框架。

您的Storage接口示例是一个很好的示例，假设Storage即使您编写了该接口，也将其视为某种外部框架。

同样，save()仅当对象是域的一部分（“语言”）时，才应允许该对象。例如，Account在调用时，我不需要显式“保存”一个transfer(amount)。我应该正确地期望业务职能transfer()将继续我的转移。

总而言之，我认为DDD的想法很好。使用无处不在的语言，通过对话，有限的上下文等来练习领域。但是，如果要与面向对象的兼容，构建块确实需要进行彻底的检查。有关详细信息，请参见链接的卡座。

也许我们可以将保存委托给另一个对象

避免不必要地传播领域知识。对单个字段了解的越多，添加或删除字段就越困难：

public class Product {
    private String name;
    private Double price;

    void save(Storage storage) {
        storage.save( toString() );
    }
}

在这里，产品不知道您要保存到日志文件还是数据库或同时保存到两者。在这里，保存方法不知道您有4个字段还是40个字段。那是松散耦合的。这是好事。

当然，这仅是如何实现此目标的一个示例。如果您不喜欢构建和解析用作DTO的字符串，则还可以使用集合。LinkedHashMap是我的最爱，因为它可以保留顺序，并且toString（）在日志文件中看起来不错。

无论您做什么，都请不要传播周围领域的知识。这是人们经常忽略的一种耦合形式，直到很晚为止。我想要很少的事情来静态地知道我的对象有多少个字段。这样，添加字段不会在很多地方涉及很多编辑。

已经提到的模式还有另一种选择。Memento模式非常适合封装域对象的内部状态。内存对象表示域对象公共状态的快照。域对象知道如何从其内部状态创建此公共状态，反之亦然。然后，存储库仅适用于州的公共代表。这样，内部实现就与任何持久性细节脱钩了，它只需要维护公共合同即可。同样，您的域对象也不必公开确实会使其变得贫乏的任何吸气剂。

有关该主题的更多信息，我推荐一本很棒的书：Scott Millett和Nick Tune撰写的“域驱动设计的模式，原理和实践”