原则7：设计和测试一个功能得尽可能的独立。当你做设计时，应该想想这一条。从长远来看这能给你解决很多问题，否则你的功能只能等待系统其他所有的功能都就绪了才能测试，这显然很不好。有了这个原则，

依然是上面的forYes方法。我们把exist的逻辑单独抽取了一个方法，同时又把主逻辑代码也抽了一个方法，你会发现forYes1方法的代码长度并没有增加多少，依然保持的良好的可读性。

我们看到有三个部分：description、request、response。通过request定义了请求时的url和method，然后通过response约定返回时的headers和body信息。

在src/main/resources/templates目录下创建两个文夹“mobile”和“tablet”，然后创建对应的Freemarker文件，最后的结构像下面这样：

events的缩写。这是个什么鬼。其实就是个概念。或者是一个标准。就是把数据从web服务端传输到客户端的一种做法。顾名思义：服务端发送给客户端的事件。神奇吧。

上集：微服务业务开发三个难题－拆分、事务、查询（上）上集我们阐述了使用微服务体系架构的关键障碍是领域模型，事务和查询，这三个障碍似乎和功能拆分具有天然的对抗。只要功能拆分了，就涉及这三个难题。然后我们向你展示了一种解决方案就是将每个服务的业务逻辑实现为一组DDD聚合。然后每个事务只能更新或创建一个单独的聚合。然后通过事件来维护聚合（和服务）之间的数据一致性。在本集中，我们将会向你介绍使用事件的时候遇到了一个新的问题，就是怎么样通过原子方式更新聚合和发布事件。然后会展示如何使用事件源来解决这个问题，事件源是一种以事件为中心的业务逻辑设计和持久化的方法。之后，我们会阐述微服务架构下的查询困难的问题。然后向你介绍一种称为命令查询责任分离（CQRS）的方法来实现可扩展和高性能的查询。

-查询管理数据一致性不是唯一的挑战。还有一个问题就是查询问题。在传统的单体应用中，我们通常使用join来实现跨表查询。比如，我们可以通过下面的sql轻松的查询出最近客户所订的大额订单：SELECT