1.业务服务

业务服务是业务层对外的统一门面，它由三方面组成：业务接口、入参、出参。

a) 业务接口

一个业务接口代表一个领域的业务服务，比如订单域的业务服务就由接口OrderService表示，会员域的业务服务就由接口MemberService表示。

接口可以按照执行性质分为读接口和写接口，比如OrderReadService和OrderWriteService。读写分离的好处是可以对集群进行读写分组，从而管理流量，当然，单机系统读写分离意义不是太大。

领域内的操作则以业务接口中的方法的形式体现，比如订单域有下单createOrder，取消订单cancelOrder等等操作。

对于这些操作，尽量设计出有业务含义的方法，而不是增删改查，当然，对于一些简单的业务，也只能增删改查。

b)入参

接下来，是入参的设计。入参对于读方法，比较简单，不做讨论。对于写方法，我们将入参设计成有层次的数据模型。

首先需要设计出公共的数据模型，比如订单数据模型，商家数据模型，商品数据模型等，然后将这些数据模型和一些特定业务下的个性数据结合，组成Request对象，

这个request对象按照不同业务操作不同而不同，对应的返回结果就是response，它也是随着不同业务返回的参数不同。

举个例子：

       拿下餐饮订单来说，首先，我们应该识别出这些业务流程中一些比较基础的数据模型，比如餐饮领域的菜品、桌位等，这些模型之所以说是基础模型，

是因为，不管下什么餐饮订单，菜品和桌位肯定是逃不了的，它们是可以被复用的！因此，我们分别为这些基础模型设计相对于的DO（Domian Object）:DishDO（菜品）、BoardDO（桌位）等等，

接下来，我们为下餐饮订单设计一个请求对象DishOrderCreateRequest其中DishOrderCreateRequest内部包含了DishDO和BoardDO，另外会包含一些特定的属性，比如人数啊，折扣啊等等，

这样一来就能做到通用和灵活兼顾，DishOrderCreateRequest代表的个性化的灵活的业务入参，而DishDO和BoardDO等则代表了不易变化的基础模型。

c) 出参

最后，是出参的设计。对于写方法，一般出参比较简单。对于读方法，出参往往是一个结构与层次比较复杂的组合对象。

比如查询一个订单，这个订单有订单基本信息，还有商品信息，收货人地址信息等。在设计出参的时候，结构上要设计成组合对象，但是真正查询的时候，通过查询选择器，去查询不同的组合对象。

比如查询选择器设置商品查询为true，地址查询为false，那么这次查询出的订单就只包含商品，而不包含地址。

2.业务流程

业务流程其实就是对业务规则的解释，只是这种解释使用代码去实现的，我们要做的其实就是准确翻译这些业务规则，并维护好这些业务规则。

业务流程中可以大致分为三种动作节点，1、组装参数节点；2、规则判断节点；3、执行动作节点；其中每个动作节点都是一些业务代码的片段。

举个例子：

      下餐饮订单，我们第一步就是将上层传入的参数组装出一个基础的DishOrderDO（组装参数节点），然后按照特定的规则去填充这个DishOrderDO（规则判断节点），然后就是调用DAO去创建DishOrderDO（执行动作节点）。

业务流程是最容易变化的地方，要想维护好业务流程并不容易，总的思想是将大的业务流程拆分成小的业务流程，抽出每个业务流程中共有的代码片段，变成可维护的业务组件。

3.业务组件

a) 基础组件

业务组件其实是将一些内聚的可复用的代码片段进行封装。和业务流程中的三种业务节点相对应，业务组件也分为三种：组装参数组件 、规则判断组件 、动作执行业务组件。

业务组件的抽象往往是对业务有了深刻理解之后才进行的，盲目地进行业务组件的抽象，往往到头来白忙活。

b) 能力

对业务组件进行进一步抽象，可以得到能力。业务能力是具有一定复用性的组件的组合，比如发短信能力=组装短信参数组件+发短信组件。对于发短信能力，可以被不同的业务流程复用，

比如订单下单成功发短信，支付成功发短信，逻辑都是相似的，只有内容不同。

能力是一种粒度比较大的组件，粒度越大，往往复用性就越小，对能力的抽取，也是基于对特定业务深刻的理解，没有一劳永逸的银弹。

c)更高纬度的抽象

对于互联网这样的需求变化极快的场景，更高纬度的组件抽象往往性价比很低，不建议大家去做。