DDD（Domain Driven Design）领域层API请求由谁负责处理

Question

我是 DDD 的初学者。

我不知道谁负责处理 API 请求。
我不知道谁负责间接依赖于基础设施层的功能。
比如带有Web API请求的函数。

例如我正在创建在线购物系统，系统支持取消订单。

我想我在领域层有 2 个类候选来实现订单取消功能。 A：域服务 B：域对象

但我无法判断哪个更好。

我担心设计“A”过于程序化，看起来很乏味。
我还担心设计“B”会使领域对象过于博学和依赖。 （因为我认为对象应该尽可能简单）

设计候选A

// Simple but anemic
class Order {
    id: number;
    date: Date;
    state: OrderState;

    constructor(
        ...
    ) {
        ...
    }
}

// Procedural
class OrderService {
    private readonly orderRepository: OrderRepository;

    constructor(
        orderRepository: OrderRepository
    ) {
        ...
    }

    cancel(orderId: number): void {
        orderRepository.update(orderId, { state: OrderSate.Cancelled });
    }
}

设计候选人 B

// knowledgeable and dependent
class Order {
    id: number;
    date: Date;
    state: OrderState;

    private readonly orderRepository: OrderRepository;

    constructor(
        orderRepository: OrderRepository,
        ...
    ) {
        ...
    }

    cancel(): void {
        orderRepository.update(this.id, { state: OrderSate.Cancelled });
    }
}

The model I thought

Answer 1

我是 DDD 的初学者。我不知道谁负责处理 API 请求。

业务逻辑属于领域模型，编排属于应用。

因此，您的应用程序中的逻辑通常看起来像...

Order order = orderRepository.get(orderId);
order.cancel();

当Order::cancel 被调用时，Order 模型负责知道如何操作它自己的内存数据结构。 OrderRepository 负责持久化。应用程序驱动其他两个元素的调用。

混淆的部分原因是“服务”这个概念被过度使用了。在 DDD 中，“域服务”是指作为域模型一部分的模式（就像值对象和实体是域模型模式一样）。

更新 20190120

但是谁更新服务器中的数据库？如果 order.cancel() 仅更新自己的内存，则您的代码似乎尚未更新服务器中的数据库。这是我的想法。

这是一个非常重要的问题，不是吗？ :)

当 Eric Evans 在他的书中首次描述存储库模式时，他特意选择了具有集合语义的存储库模式，并建议事务管理应该是一个应用程序关注点。

在伪代码中：

beginTransaction();
Order order = orderRepository.get(orderId);
order.cancel();
commitTransaction();

这个概念是底层的 mapper 可以查看存储库并发现哪些实体是“脏的”，从而生成对持久存储的适当调用。

最近，您更有可能看到具有存储的存储库，而不是集合、语义

beginTransaction();
Order order = orderRepository.get(orderId);
order.cancel();
orderRepository.save(order);
commitTransaction();

基本机制是相同的，但我们消除了共享更改方式的一些魔力。

Answer 2

这些选项还有其他选择。一种是取消存储库的事情，并让模型定义行为：

public interface Order {
    void cancel();
}

然后借助特定技术实现该行为：

public final class SqlOrder implements Order {
    ...
    @Override
    public void cancel() {
        connection.execute("update order...");
    }
}

根据您的用例，这可能会带来以下好处：不贫血，摆脱可能不必要的间接（存储库），使用领域语言而不是 CRUD 技术，更易于维护，更易于测试，因为订单只是一个现在的界面等等。