《领域驱动设计之php实现》- 应用服务【转载】

DD畏（tiwayD）

于 2022-07-12 11:21:09 发布

阅读量309

点赞数

分类专栏：架构文章标签： php 系统架构

原文链接：https://segmentfault.com/a/1190000021576876

版权

架构专栏收录该内容

17 篇文章 2 订阅

订阅专栏

应用层是将领域模型与查询或更改其状态的客户端分离的层。应用服务是此层的构建块。

正如 Vaughn Vernon 所说：“应用服务是领域模型的直接客户端。” 你可以考虑把应用服务当作外部世界（HTML 表单，API 客户端，命令行，框架，UI 等等）与领域模型自身之间的连接点。

考虑向外部展示系统的顶级用例，也许会有帮助。例如：“作为来宾，我想注册”，“作为以登录用户，我要购买产品”，等等。

在这一章，我们将解释怎样实现应用服务，理解命令模式（Command pattern）的角色，并且确定应用服务的职责。所以，让我们考虑一个注册新用户（signing up a new user）的用例。

从概念上讲，为注册新用户，我们必须：

从客户端获取电子邮箱（email）和密码（password）
检查电子邮箱（email）是否在使用
创建一个新用户（user）
将用户（user）添加到已有用户集合（user set）
返回我们刚创建的用户（user）

让我们开始干吧！

请求（Requests）

我们需要发送电子邮件（email）和密码（password）给应用服务。这有许多方法可以从客户端来做这样事情（HTML 表单，API 客户端，或者甚至命令行）。我们可以通过用方法签名发送一个标准的参数（email 和 password），或者构建并发送一个含有这些信息的数据结构。后面的这种方法，即发送 DTO，把一些有趣的功能拿到台面上。通过发送对象，可以在命令总线上对其进行序列化和排队。也可以添加类型安全和一些 IDE 帮助。

数据传输对象（Data Transfer Object）

DTO 是一种在过程之间转移数据的数据结构。不要把它误认为是一种全能的对象。DTO 除了存储和检索它自身数据（存取器），没有其他任何行为。DTO 是简单的对象，它不应该含有任何需要测试的业务逻辑。

正如 Vaughn Vernon 所说：

应用服务方法签名仅使用基本类型（整数，字符串等等），或者 DTO 作为这些方法的替代方法，更好的方法可能是设计命令对象（Command Object）。这不一定是正确或错误的方法，这主要取决于你的口味和目标。

一个含有应用服务所含数据的 DTO 实现可能像这样：


namespace Lw\Application\Service\User;
class SignUpUserRequest
{
    private $email;
    private $password;

    public function __construct($email, $password)
    {
        $this->email = $email;
        $this->password = $password;
    }

    public function email()
    {
        return $this->email;
    }

    public function password()
    {
        return $this->password;
    }
}

正如你所见，SignUpUserRequest 没有行为，只有数据。这可能来自于一个 HTML 表单或者一个 API 端点，尽管我们不关心这些。

构建应用服务请求

从你最喜欢的框架交付机制创建一个请求，应该是最直观的。

在 web 中，你可以将控制器请求中的参数打包成一个 DTO 并将它们下发给服务。
对 CLI 命令来说也是相同的原则：读取输入参数并下发。

通过使用 Symfony，我们可以提取来自 HttpFoundation 组件的请求中的所需数据：

// ...
class UsersController extends Controller
{
    /**
     * @Route('/signup', name = 'signup')
     * @param Request $request
     * @return Response
     */
    public function signUpAction(Request $request)
    {
// ...
        $signUpUserRequest = new SignUpUserRequest(
            $request->get('email'),
            $request->get('password')
        );
// ...
    }
// ...

在一个使用 Form 组件来捕获和验证参数的更精细的 Silex 应用程序上，它看起来像这样：

// ...
$app->match('/signup', function (Request $request) use ($app) {
    $form = $app['sign_up_form'];
    $form->handleRequest($request);
    if ($form->isValid()) {
        $data = $form->getData();
        try {
            $app['sign_in_user_application_service']->execute(
                new SignUpUserRequest(
                    $data['email'],
                    $data['password']
                )
            );
            return $app->redirect(
                $app['url_generator']->generate('login')
            );
        } catch (UserAlreadyExistsException $e) {
            $form
                ->get('email')
                ->addError(
                    new FormError(
                        'Email is already registered by another user'
                    )
                );
        } catch (Exception $e) {
            $form
                ->addError(
                    new FormError(
                        'There was an error, please get in touch with us'
                    )
                );
        }
    }
    return $app['twig']->render('signup.html.twig', [
        'form' => $form->createView(),
    ]);
});

请求的设计

在设计你的请求对象时，你应该总是遵循这些原则：使用基本类型，序列化设计，并且不包含业务逻辑在里面。这样，你可以在单元测试时节省开支。

使用基本类型

我们推荐使用基本类型来构建你的请求对象（就是字符串，整数，布尔值等等）。我们仅仅是抽象出输入参数。你应该能够从交付机制当中独立地消费应用服务。即使是非常复杂的 HTML 表单，也总是可以在控制器级别转换为基本类型。你应该不想混淆你的框架和业务逻辑。

在某些情况下，很容易直接使用值对象。不要这样做。值对象定义的更新将影响所有客户端，并且你会将客户端与领域逻辑耦合在一起。

序列化

使用基本类型的一个副作用就是，任何请求对象可以轻松地序列化为字符串，发送并存储在消息系统或者数据库中。

无业务逻辑

避免在你的请求对象中加入任何业务甚至验证逻辑。验证应该放到你的领域中（这里指的是实体，值对象，领域服务等等）。验证是保持业务不变性和领域约束的方法。

无测试

应用程序请求是数据结构，不是对象。数据结构的单元测试就像测试 getters 和 setters。这没有行为需要测试，因此对请求对象和 DTO 进行单元测试没有太多价值。这些结构将作为更复杂的测试（例如集成测试或验收测试）的副作用而覆盖。

命令是请求对象的替代方法。我们设计一个具有多种应用方法服务，并且每个方法都含有你放到 Request 中的参数。对于简单的应用程序来说这是可以的，但后面我们就得操心这个问题。

应用服务剖析

当我们在请求中封装好了数据，就该处理业务逻辑了。正如 Vaughn Vernon 所说：“尽量保证应用服务很小很薄，仅仅用它们在模型上协调任务。”

首先要做的事情就是从请求中提取必要信息，即 email 和 password。必要的话，我们需要确认是否含有特殊 email 的用户。如果不关心这些的话，那么我们创建和添加用户到 UserRepository。在发现有用户具有相同 email 的特殊情况下，我们抛出一个异常以便客户端以自己的方式处理（显示错误，重试，或者直接忽略它）。

namespace Lw\Application\Service\User;

use Ddd\Application\Service\ApplicationService;
use Lw\Domain\Model\User\User;
use Lw\Domain\Model\User\UserAlreadyExistsException;
use Lw\Domain\Model\User\UserRepository;

class SignUpUserService
{
    private $userRepository;

    public function __construct(UserRepository $userRepository)
    {
        $this->userRepository = $userRepository;
    }

    public function execute(SignUpUserRequest $request)
    {
        $email = $request->email();
        $password = $request->password();
        $user = $this->userRepository->ofEmail($email);
        if ($user) {
            throw new UserAlreadyExistsException();
        }
        $this->userRepository->add(
            new User(
                $this->userRepository->nextIdentity(),
                $email,
                $password
            )
        );
    }
}

漂亮！如果你想知道构造函数里的 UserRepository 是做什么的，我们会在后续向你展示。

处理异常

应用服务抛出异常是向客户端反馈不正常的情况和流程的方法。这一层上的异常与业务逻辑有关（像查找一个用户），但并不是实现细节（像 PDOException，PredisException, 或者 DoctrineException）。

依赖倒置

处理用户不是服务的职责。正如我们在第 10 章，仓储中所见，有一个专门的类来处理 User 集合：UserRepository。这是一个从应用服务到仓储的依赖。我们不想用仓储的具体实现耦合应用服务，因此这之后会导致我们用基础设施细节耦合服务。所以我们依赖具体实现依赖的契约（接口），即 UserRepository。

UserRepository 的特定实现会在运行时被构建和传送，例如用 DoctrineUserRepository，一个使用 Doctine 的专门实现。传递一个专门的实现在测试时同样正常。例如，NotAvailableUserRepository 可以是一个专门的实现，它会在一个操作每个执行时抛出一个异常。这样，我们可以测试所有应用服务行为，包括悲观路径（sad paths），即使当出现了问题，应用服务也必须正常工作。

应用服务也可以依赖领域服务（如 GetBadgesByUser）。在运行时，此类服务的实现可能相当复杂。可以想像一个通过 HTTP 协议整合上下文的 HttpGetBadgesByUser。

依赖抽象，我们可以使我们的应用服务不受底层基础设施更改的影响。

应用服务实例

仅实例化应用服务很容易，但根据依赖构建的复杂度，构建依赖树的可能很棘手。为此，大多数框架都带有依赖注入容器。如果没有，你最后会在控制器的某处得到类似以下的代码：

$redisClient = new Predis\Client([
    'scheme' => 'tcp',
    'host' => '10.0.0.1',
    'port' => 6379
]);
$userRepository = new RedisUserRepository($redisClient);
$signUp = new SignUpUserService($userRepository);
$signUp->execute(new SignUpUserRequest(
    'user@example.com',
    'password'
));

我们决定为 UserRepository 使用 Redis 的实现。在之前的代码示例中，为构建一个在内部使用 Redis 的仓储，我们构建了所有所需的依赖项。

这些依赖是：一个 Predis 客户端，以及所有连接到 Redis 服务器的参数。这不仅效率低下，还会在控制器内重复传播。

你可以将创建逻辑重构为一个工厂，或者你可以使用依赖注入容器（大多数现代框架都包含了它）。

使用依赖注入容器是否不好？

一点也不。依赖注入只是一个工具。它们有助于剥离构建依赖时的复杂性。对构建基础构件也很有用。Symfony 提供了一个完整的实现。

请考虑以下事实，将整个容器作为一个整体传递给服务之一是不好的做法。这就像将整个应用程序的上下文与领域耦合在一起。如果一个服务需要指定的对象，请从框架来创建它们，并且把它们作为依赖传递给服务。但不要使服务觉察到其中的上下文。

让我们看看如何在 Silex 中构建依赖：

$app = new \Silex\Application();
$app['redis_parameters'] = [
    'scheme' => 'tcp',
    'host' => '127.0.0.1',
    'port' => 6379
];
$app['redis'] = $app->share(function ($app) {
    return new Predis\Client($app['redis_parameters']);
});
$app['user_repository'] = $app->share(function($app) {
    return new RedisUserRepository(
        $app['redis']
    );
});
$app['sign_up_user_application_service'] = $app->share(function($app) {
    return new SignUpUserService(
        $app['user_repository']
    );
});
// ...
$app->match('/signup' ,function (Request $request) use ($app) {
// ...
    $app['sign_up_user_application_service']->execute(
        new SignUpUserRequest(
            $request->get('email'),
            $request->get('password')
        )
    );
// ...
});

正如你所见，$app 被当作服务容器使用。我们注册了所有所需的组件，以及它们的依赖。sign_up_user_application_service 依赖上面的定义。改变 user_repository 的实现就像返回其他东西一样简单（MySQL，MongoDB 等等），所以我们根本不需要改变服务代码。

Symfony 应用里等效的内容如下：

<?xml version=" 1.0" ?>
<container xmlns="http://symfony.com/schema/dic/services"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="
http://symfony.com/schema/dic/services
http://symfony.com/schema/dic/services/services-1.0.xsd">
    <services>
        <service
                id="sign_up_user_application_service"
                class="SignUpUserService">
            <argument type="service" id="user_repository" />
        </service>
        <service
                id="user_repository"
                class="RedisUserRepository">
            <argument type="service">
                <service class="Predis\Client" />
            </argument>
        </service>
    </services>
</container>

现在，你有了在 Symonfy Service Container 中的应用服务定义，之后获取它也非常直观。所有交付机制（Web 控制器，REST 控制器，甚至控制台命令）都共享相同的定义。在任何实现 ContainerWare 接口的类上，服务都是可用的。获取服务与 $this->get(‘sign_up_user_application_service’) 一样容易。

总而言之，你怎样构建服务（adhoc，服务容器，工厂等等）并不重要。重要的是保持你的应用服务设置在基础设施边界之外。

自定义一个应用服务

自定义服务的主要方法是选择你要传递的依赖。根据你服务容器能力，这可能有一点棘手，因此你可以添加一个 setter 方法来即时改变依赖。例如，你可能需要更改依赖输出，以便你能设置一个默认项然后改变它。如果逻辑变得过于复杂，你可以创建一个应用服务工厂，它可以为你处理这种局面。

执行

这有两种调用应用服务的方法：一个是每个用例对应一个含有单个 execution 方法的专用类，以及多个应用服务和用例在同一个类。

一个类一个应用服务

这是我们更喜欢的方法，并且这可能适合所有场景：

class SignUpUserService
{
// ...
    public function execute(SignUpUserRequest $request)
    {
// ...
    }
}

每个应用服务使用一个专用的类使得代码在应对外部变化时更健壮（单一职责原则）。这几乎没有原因去改变类，因为服务仅仅只做一件事。应用服务会更容易测试，理解，因为它们只做一件事。这使得实现一个通用的应用服务契约更容易，使类装饰更简单（查看第 10 章，仓储的子章节事务）。这将同样会更高内聚，因为所有依赖由单一的用例所独有。

execution 方法可以有一个更具表达性的名称，例如 signUp。但是，命令模式的执行通过应用服务标准格式化了通用契约，从而使得这更容易装饰，这对于事务非常方面。

一个类多个应用服务方法
有时候，将内聚的应用服务组织在同一个类中可能是个好主意：

class UserService
{
// ...
    public function signUp(SignUpUserRequest $request)
    {
// ...
    }
    public function signIn(SignUpUserRequest $request)
    {
// ...
    }
    public function logOut(LogOutUserRequest $request)
    {
// ...
    }
}

我们并不推荐这种做法，因为并不是所有应用服务都 100% 内聚的。一些服务可能需要不同的依赖，从而导致你的应用服务依赖其并不需要的东西。另一个问题是这种类会快速成长。因为它违反了单一职责原则，这将导致有多种原因改变它从而破坏它。

返回值

注册后，我们可能会考虑将用户重定向到个人资料页面。回传所需信息给控制器最自然的方式是直接从服务中返回实体。

class SignUpUserService
{
// ...
    public function execute(SignUpUserRequest $request)
    {
        $user = new User(
            $this->userRepository->nextIdentity(),
            $email,
            $password
        );
        $this->userRepository->add($user);
        return $user;
    }
}

然后，我们会从控制器中拿到 id 字段，然后重定向到别的地方。但是，三思而后行。我们返回了功能齐全的实体给控制器，这将使得交付机制可以绕过应用层直接与领域交互。

假设 User 实体提供了一个 updateEmailAddress 方法。你可以不这样做，但从长远来看，有人可能会考虑使用它：

$app-> match( '/signup' , function (Request $request) use ($app) {
// ...
    $user = $app['sign_up_user_application_service']->execute(
        new SignUpUserRequest(
            $request->get('email'),
            $request->get('password'))
    );
    $user->updateEmailAddress('shouldnotupdate@email.com');
// ...
});

不仅仅是那样，而且表现层所需的数据与领域管理的数据不相同。我们并不想围绕表现层演变和耦合领域层。相反，我们想自由进化。

为达到此目的，我们需要一种弹性的方式来解耦这两层。

来自聚合实例的 DTO

我们可以用表现层所需的信息返回干净的（sterile）数据。正如我们之前所见，DTO 非常适合这种场景。我们仅仅需要在应用服务中组合它们并将其返回给客户端：

class UserDTO
{
    private $email ;
// ...
    public function __construct(User $user)
    {
        $this->email = $user->email ();
// ...
    }
    public function email ()
    {
        return $this->email ;
    }
}

UserDTO 将在表现层上从 User 实体暴露我们任何所需的数据，从而避免暴露行为：

class SignUpUserService
{
    public function execute(SignUpUserRequest $request)
    {
// ...
        $user = // ...
    return new UserDTO($user);
    }
}

使命达成！现在我们可以把参数传给模板引擎并把它们转换进挂件（widgets），标签（tags），或者子模板（subtemplates），或者用数据做任何我们想在表现层一侧所做的：

$app->match('/signup' , function (Request $request) use ($app) {
    /**
     * @var UserDTO $user
     */
    $userDto=$app['sign_up_user_application_service']->execute(
        new SignUpUserRequest(
            $request->get('email'),
            $request->get('password')
        )
    );
// ...
});

但是，让应用服务决定如何构建 DTO 揭示了另一个限制。由于构建 DTO 仅仅取决于应用服务，因此很难适配不同的客户端。考虑在同一用例上，Web 控制器重定向所需的数据和 REST 响应所需的数据，根本不相同。

让我们允许客户端通过传递特定的 DTO 汇编器（Assembler）来定义如何构建 DTO：

class SignUpUserService
{
    private $userDtoAssembler;
    public function __construct(
        UserRepository $userRepository,
        UserDTOAssembler $userDtoAssembler
    ) {
        $this->userRepository = $userRepository;
        $this->userDtoAssembler = $userDtoAssembler;
    }
    public function execute(SignUpUserRequest $request)
    {
        $user = // ...
    return $this->userDtoAssembler->assemble($user);
    }
}

现在客户端可以通过传递一个指定的 UserDTOAssembler 来自定义回复。

数据转换器（Data Transformer）

在一些情况下，为更复杂回复（像 JSON，XML，CSV，和 iCAL 契约）生成中间 DTO 可能被视为不必要的开销。我们可以将表述输出到缓冲区中，然后在交付端获取它。

转换器有助于降低由高层次领域概念到低层次客户端细节的开销。让我们看一个例子：

interface UserDataTransformer
{
    public function write(User $user);
    /**
     * @return mixed
     */
    public function read();
}

考虑为一个给定产品生成不同的数据表述的示例。通常，产品信息通过一个 web 接口（HTML）提供，但我们可能对提供其他格式感兴趣，例如 XML，JSON，或者 CSV。这可能会启动与其他服务的集成。

考虑一个类似 blog 的例子。我们可以用 HTML 暴露我们潜在的作者给外部，但一些用户对通过 RSS 消费我们的文章感兴趣。这个用例（应用服务）仍然相同。而表述却不一样。

DTO 是一个干净且简单的方案，它能够以不同表述形式传递给模板引擎，但最后数据转换这一步的逻辑可能有点复杂，因为这样的模板逻辑可能会成为一个需要维护，测试和理解的问题。

数据转换器可能在特定的例子上会更好。他们对领域概念（聚合，实体等等）来说是黑盒子，因为输入和只读表述（XML，JSON，CSV 等等）与输出一样。这些转换器也很容易测试：


class JsonUserDataTransformer implements UserDataTransformer
{
    private $data;
    public function write(User $user)
    {
// More complex logic could be placed here
// As using JMSSerializer, native json, etc.
        $this->data = json_encode($user);
    }
    /**
     * @return string
     */
    public function read()
    {
        return $this->data;
    }
}

这很简单。想知道 XML 或者 CSV 是怎样的？让我们看看怎样通过应用服务整合数据转换器：


class SignUpUserService
{
    private $userRepository;
    private $userDataTransformer;
    public function __construct(
        UserRepository $userRepository,
        UserDataTransformer $userDataTransformer
    ) {
        $this->userRepository = $userRepository;
        $this->userDataTransformer = $userDataTransformer;
    }
    public function execute(SignUpUserRequest $request)
    {
        $user = // ...
            $this->userDataTransformer()->write($user);
    }
    /**
     * @return UserDataTransformer
     */
    public function userDataTransformer()
    {
        return $this->userDataTransformer;
    }
}

这与 DTO 汇编器方法相似，但是这一次没有返回一个具体的值。数据转换器用来持有数据和与数据交互。

使用 DTO 最主要的问题是过度写入它们。大多数时候，你的领域概念和 DTO 表述会呈现相同的结构。大多数时候，你会觉得没必要花时间去做一个这样的映射。这的确令人沮丧，表述与聚合的关系不是 1:1。你可以将两个聚合以一个表述呈现。你也可以用多种方式呈现同一相聚合。你怎样做取决于你的用例。

不过，依据 Martin Fowler 所说：

当你在表现展示台的模型与基础领域模型之间存在重大不匹配时，使用 DTO 之类的方法很有用。在这种情况下，从领域模型映射特定表述的外观/网关（facade/gateway并且为表述呈现一个方便的接口是有意义的。这是值得做的，但是仅对于具有这种不匹配的场景才值得做（在这种情况下，这不是多余的工作，因为无论如何你都需要在场景下进行操作。）

我们认为从长远角度来看是值得投资的。在大中型项目中，接口表述和领域概念总是无规律的变化。你可能想将它们各自解耦以便为更新降低摩擦。使用 DTO 或数据转换器允许你自由演变模型而不必总是考虑破坏布局（layout）。

复合层上的多个应用服务

大多数时候，布局（layout）总是与单个应用服务不一样。我们的项目有相同复杂的接口。

考虑一个特定项目的首页。我们该怎样渲染如此多的用例？这有一些选项，让我们看看吧。

AJAX 内容的集成

你可以让浏览器直接通过 AJAX 或 Hijax 请求不同端点并在布局上组合数据。这可以避免在你的控制器混合多个应用服务，但它可能有性能开销，因为触发了多个请求。

ESI 内容的集成

Edge Side Includes（ESI）是一种小型的标记语言，与之前的方法相似，但是是在服务器端。它需要额外的精力来配置额外的中间件，例如 NGINX 或 Varnish，以使其正常工作。

Symfony 子请求

如果你使用 Symfony，子请求可能是一个有趣的选择。依据 Symfony Documentation：

除了发送给 HttpKernel::handle 的主请求之外，你也可以发送所谓的子请求（sub request）。子请求的外观和行为看起来与其它请求一样，但通常用来渲染页面的一小部分而不是整个页面。你大多数时候从控制器发送子请求（或者从模板内部，它由你的控制器渲染）。这会创建了另一个完整的请求 - 回复周期，在此周期，新的请求被转换为回复。内部唯一不同的是一些监听器（例如，安全）只能根据主请求执行操作。每个监听器都传递 KernelEvent 的某个子类，该子类的 MasterRequest() 可用于检查当前请求是主请求还是子请求。

这非常棒，因为在没有 AJAX 开销或者不使用复杂的 ESI 配置的情况下，你将会从调用独立的应用服务中受益。

一个控制器（controller），多个应用服务

最后一个选择可能是用同一个控制器管理多个应用服务，从而控制器的逻辑会变得有点脏，因为它要处理和合成传递给视图的回复。

测试应用服务

由于你对测试应用服务自身行为感兴趣，因此没必要将其转换为具有针对真实数据的复杂设置的集成测试。你对测试低层次细节是不感兴趣的，因此在大多数情况下，单元测试就足够了。

class SignUpUserServiceTest extends \PHPUnit_Framework_TestCase
{
    /**
     * @var \Lw\Domain\Model\User\UserRepository
     */
    private $userRepository;
    /**
     * @var SignUpUserService
     */
    private $signUpUserService;

    public function setUp()
    {
        $this->userRepository = new InMemoryUserRepository();
        $this->signUpUserService = new SignUpUserService(
            $this->userRepository
        );
    }

    /**
     * @test
     * @expectedException
     * \Lw\Domain\Model\User\UserAlreadyExistsException
     */
    public function alreadyExistingEmailShouldThrowAnException()
    {
        $this->executeSignUp();
        $this->executeSignUp();
    }

    private function executeSignUp()
    {
        return $this->signUpUserService->execute(
            new SignUpUserRequest(
                'user@example.com',
                'password'
            )
        );
    }

    /**
     * @test
     */
    public function afterUserSignUpItShouldBeInTheRepository()
    {
        $user = $this->executeSignUp();
        $this->assertSame(
            $user,
            $this->userRepository->ofId($user->id())
        );
    }
}

我们为 User 仓储提供了一个内存实现。这就是所谓的 Fake：仓储的全功能实现使我们的测试成为一个单元。我们不需要去测试类的行为。那会使我们的测试缓慢而脆弱。

检查领域事件的归属也很有趣。如果创建用户触发了用户注册的事件，则确保该事件触发可能是一个好主意：

class SignUpUserServiceTest extends \PHPUnit_Framework_TestCase
{
// ...
    /**
     * @test
     */
    public function itShouldPublishUserRegisteredEvent()
    {
        $subscriber = new SpySubscriber();
        $id = DomainEventPublisher::instance()->subscribe($subscriber);
        $user = $this->executeSignUp();
        $userId = $user->id();
        DomainEventPublisher::instance()->unsubscribe($id);
        $this->assertUserRegisteredEventPublished(
            $subscriber, $userId
        );
    }
    private function assertUserRegisteredEventPublished(
        $subscriber, $userId
    ) {
        $this->assertInstanceOf(
            'UserRegistered', $subscriber->domainEvent
        );
        $this->assertTrue(
            $subscriber->domainEvent->userId()->equals($userId)
        );
    }
}
class SpySubscriber implements DomainEventSubscriber
{
    public $domainEvent;
    public function handle($aDomainEvent)
    {
        $this->domainEvent = $aDomainEvent;
    }
    public function isSubscribedTo($aDomainEvent)
    {
        return true;
    }
}

事务

事务是与持久化机制相关的实现细节。领域层不需要关心底层实现细节。考虑在这一层开始，提交，或者回滚一个事务是种坏味道。这一层的细节属于基础设施层。

处理事务最好的方式是不处理它们。我们可以用一个装饰器包装我们的应用服务来自动处理事务会话。

我们已经在我们的一个仓储中为这个问题实现了一个方案，同时你可以在这里检查它：

interface TransactionalSession
{
    /**
     * @return mixed
     */
    public function executeAtomically(callable $operation);
}

这个契约只用了一小块代码并且自动执行。取决于你的持久化机制，你会得到不同的实现。

让我们看看怎样用 Doctrine ORM 来做：

class DoctrineSession implements TransactionalSession
{
    private $entityManager;

    public function __construct(EntityManager $entityManager)
    {
        $this->entityManager = $entityManager;
    }

    public function executeAtomically(callable $operation)
    {
        return $this->entityManager->transactional($operation);
    }
}

客户端是怎样使用上面的代码：

/** @var EntityManager $em */
$nonTxApplicationService = new SignUpUserService(
    $em->getRepository('BoundedContext\Domain\Model\User\User')
);
$txApplicationService = new TransactionalApplicationService(
    $nonTxApplicationService,
    new DoctrineSession($em)
);
$response = $txApplicationService->execute(
    new SignUpUserRequest(
        'user@example.com',
        'password'
    )
);

现在我们有了事务会话的 Doctrine 实现，为我们的应用服务创建一个装饰器会很棒。通过这种方法，我们使得事务性请求对领域透明化：

class TransactionalApplicationService implements ApplicationService
{
    private $session;
    private $service;
    public function __construct(
        ApplicationService $service, TransactionalSession $session
    ) {
        $this->session = $session;
        $this->service = $service;
    }
    public function execute(BaseRequest $request)
    {
        $operation = function () use ($request) {
            return $this->service->execute($request);
        };
        return $this->session->executeAtomically($operation);
    }
}

使用 Doctrine Session 的一个很好的副作用是，它会自动管理 flush 方法，因此你无需在领域或基础设施中添加 flush。

安全

如果你想知道一般如何管理和处理用户凭据和安全性，除非这是你领域的责任，否则我们建议让框架来处理它。用户会话是交付机制的关注点。用这样的概念污染领域将使开发变得更加困难。

领域事件

领域事件监听器不得不在应用服务执行之前配置好，否则没有人会被通知到。在某些情况下，必须先明确并配置监听器，然后才能执行应用服务。

// ...
$subscriber = new SpySubscriber();
DomainEventPublisher::instance()->subscribe($subscriber);
$applicationService = // ...
$applicationService->execute(...);

大多数时候，这可以通过配置依赖注入容器做到。

命令助手（Command Handlers）

执行应用服务的一个有趣的方式是通过一个命令总线（Command Bus）库。一个好的选择是 Tactician。来自 Tactician 官网上的介绍：

什么是命令总线？这个术语大多数用于当我们用服务层组合命令模式时。它的职责是取出一个命令对象（描述用户想做什么）并且匹配一个 Handler（用来执行）。这可以使你的代码结构整齐。

我们的应用服务就是服务层，并且我们的请求对象看起来非常像命令。

如果我们有一个链接到所有应用服务的机制，并且基于请求执行正确的请求，那不是很好吗？好吧，这实际上就是命令总线。

Tiactician 库和其他选择

Tactician 是一个命令总线库，它允许你在应用服务中使用命令模式。它对于应用服务尤其方便，但是你可以使用任何输入形式。

让我们看看 Tiactician 官网的例子：

// You build a simple message object like this:
class PurchaseProductCommand
{
    protected $productId;
    protected $userId;
// ...and constructor to assign those properties...
}
// And a Handler class that expects it:
class PurchaseProductHandler
{
    public function handle(PurchaseProductCommand $command)
    {
// use command to update your models, etc
    }
}
// And then in your Controllers, you can fill in the command using your favorite
// form or serializer library, then drop it in the CommandBus and you're done!
$command = new PurchaseProductCommand(42, 29);
$commandBus->handle($command);

这就是了，Tactician 是 $commandBus 服务。它搭建了所有查找正确的 handler 和方法的管道，这可以避免许多样板代码，这里命令和 Handlers 仅仅是正常的类，但是你可以配置最适合你应用的一个。

总而言之，我们可以总结，命令就是请求对象，并且命令 Handlers 就是应用服务。

Tactician 一个非常酷的地方就是它们非常容易扩展。Tactician 为公用任务提供插件，像日志和数据库事务。这样，你可以忘掉在每个 handler 上做的连接。

Tactician 另一个有意思的插件言归正传 Bernard 集成。Bernard 是一个异步工作队列，它允许你将一些任务放到之后的进程。大量的进程会阻碍回复。大多数时候，我们可以分流以及在之后延迟它们的执行。最佳实践是，一旦分支进程完成，就立刻回复消费者让他们知道。

Matthias Noback 开发了另一个相似的项目，叫做 SimpleBus，它可以作为 Tactician 的替代方案。主要区别是 SimpleBus Command Handlers 没有返回值。

小结

应用服务呈现你限界上下文中的应用服务。高层次的用例应该简单且薄，因为它们的目的是围绕领域协调演变。应用服务是领域逻辑交互的入口。我们看到请求和命令保持事物有条不紊。DTO 和数据转换器允许我们从领域概念中解耦数据表述。用依赖注入容器构建应用服务非常直观。并且在复杂布局中组合应用服务，我们有大量的方法。