Spring Cloud工程模块划分

现在网络上都在讲Spring Cloud的各个组件，但当我们自己也把Spring Cloud引入进来的时候，却发现第一个要解决的问题是：

工程的模块如何划分

在之前我写过一篇重构购物车的过程的文章，下面就以这个购物车工程，来说明当时我是如何思考和如何做的。

工程要分几个模块

API模块

当时的购物车工程是基于Spring Cloud搭建的，并对外暴露Resful接口。那么第一个要思考的问题是，调用方如何使用购物车的微服务接口呢。有一种方式是由服务提供方生成一个SDK包，调用方引入SDK直接使用。这种方式目前应该是主流的做法，我个人也比较推崇这种方式。

因此，在工程里，我们应该有个API工程，这个工程定义了所有的微服务接口，然后可以使用一些构建工具，生成一个SDK包。

shopcart-api

这个API工程只有两样东西，一个是微服务接口，另外一个是DTO对象。可以用package来区分。

shopcart-api
     api  //包名
     dto  //包名

API包里可以用interface定义出所有的微服务接口。

public interface ShopCartApi {
    @RequestMapping(value = "/addToCart", method = RequestMethod.POST)
    ResponseDTO addToCart(@RequestBody(required = false) AddToCartDTO request) throws Exception;

    //其他接口
}

至于DTO,是用于网络传输的对象。当我们想提供微服务接口的时候，首先要考虑的就是入参和出参。一般来说可以用DTO来表示的，所有DTO对象都必须以DTO结尾。这些DTO会以SDK包的形式，被调用方使用，调用方也必须将自己的业务数据封装成DTO入参，然后才能调用后端的微服务接口。

后面我们只需要使用Maven或者Gradle，构建一个SDK包出来即可。如果是使用Maven，那么组合使用

mvn clean install
mvn clean deploy

就可以生成SDK包，并且上传到公司的Maven私服上了。

server工程

server工程用于存放controller的,是实际对外的resful微服务接口。

shopcart-server

server工程必须依赖api工程，并去实现API工程定义的微服务接口。

@RestController
public class ShopCartController implements ShopCartApi {
    @Override
    public ResponseDTO addSkuToShopCart(@RequestBody AddToCartDTO request) throws Exception {
        return null;
    }
}

这里的ShopCartApi就是之前在API工程里面定义的interface。那么server工程里的微服务接口可以直接去实现复杂的业务逻辑吗？还是说再抽取一个模块出来，专门用于实现业务逻辑呢？有一些公司，直接就在server工程里实现复杂的业务逻辑，然后用一个service包，将业务逻辑servce类放入进去。理由是，再抽取一个service模块用处不大呀，又无需用它来单独build一个包，供外部使用。其实这样做也没啥问题，但是通常来说，业务逻辑实现类，最好还是单独抽取成一个模块，除了层次清晰一些之外，业务逻辑实现类还有另外一些职责，就是【稳定】【灵活】【复用】【易于测试】，是需要精心设计的，建议别跟controller混在一个模块里。

随着业务不断的增多，server工程里的controller接口会不断的增多和变化，但是经过精心设计的业务逻辑层，却未必。

以业务BO对象【复用】举个例子，优惠券是电商营销系统中的重要营销手段，一般在购物车或者订单结算页面会给用户推荐一张最符合订单金额的优惠券，这种场景下，我们可以定义一个BO对象和DTO对象

public class CouponBO {
  //优惠券ID
  private Integer id;

  //优惠券面额
  private String denomination;

  //优惠券门槛
  private String limitMoney;

  //优惠券名称
  private String couponName;

  //优惠券状态
  private Integer status;

}

public class CouponDTO {
  //优惠券ID
  private Integer id;

  //优惠券面额
  private String denomination;

  //优惠券门槛
  private String limitMoney;

}

上面的CouponDTO对象中三个字段是前端用于展示用户最优的那张优惠券需要使用到的，当有另外一个需求，说，用户可以访问自己的优惠券列表信息，列表中要显示每张优惠券的名字和优惠券的使用状态。那么我们的CouponBO无需修改，只需要再增加一个新的优惠券DTO对象即可。也即是说，一个BO对象可以对应多个DTO对象，DTO是应对前端多变的需求而使用的，DTO对象不怕多，只是展示用的。

service工程

shopcart-service

如上所说，建议再建立一个service工程，将核心的业务逻辑封装起来。service层对外暴露的对象是业务对象，统一以BO结尾。这里就会有个问题，server工程调用完service层的接口，获取到BO对象后，需要转换成DTO对象。不过现在已经有非常成熟性能又好的映射工具了。orika就是其中的佼佼者。

模块之间的依赖

server工程依赖api工程和service工程。

需要再搞个domain模块吗

我理解的domain也属于业务逻辑的一部分，我个人是不太喜欢再搞个domain模块的，直接将domain放置在service模块里即可。

客户端如何调用服务端

在Spring Cloud里，可以借助feign

@FeignClient(value = "xxxxx",path = "/yyyyy")
public interface ShopCartClient extends ShopCartApi {

}

这里的ShopCartApi就是购物车工程中api模块的接口类。想要调用购物车的接口，直接使用ShopCartClient类即可。

进一步的思考

如果是使用Spring Cloud来提供微服务的话，由于是Resful协议的，那么调用方也可以不用SDK的方式来调用服务方接口，直接用RestTemplate调用即可，客户端的接入成本很低，也不用担心SDK的接口版本问题。
使用SDK来调用服务端接口的方式，使用起来确实比较方便，不看接口文档都可以直接编程了。但是要小心服务端接口的版本问题。
听网友说feign不灵活，目前就我自己的使用情况看，还好，欢迎网友在本文评论中说出自己的看法。
部分网友也提出，微服务工程本来就很细粒度了，无需在微服务工程里再分模块了，不然会增加复杂度，我觉得有一定的道理，但是目前我还是倾向于分模块哈。。

使用领域驱动设计来划分模块

也有些公司，使用领域驱动设计来划分模块，这块我目前还不太熟悉，不过看起来挺高大上的，也希望网友在文章的评论里，多多发表意见。

写一篇文章不容易哈，觉得文章写的还行，请在文章上方右侧的位置点一下赞哈,万分感谢。