DDD 实践思考

1. 服务分层

我在这两年中的一个大型项目使用的是SpringBoot + Dubbo + Mybatis Plus的技术栈，项目结构分为 应用层 applicationService， service服务层，domain领域层；

1. applicationService是一个http服务，对外暴露http接口，具有的基础功能有：认证权限校验，access_log，参数校验，数据封装，异常统一处理。
2. service服务层，对内暴露dubbo接口，提供封装过后的业务逻辑
3. domain领域层，和service服务层起始是在一起的，只是从代码层面进行隔离，提供细粒度的功能函数

在实践中，随着业务功能的不断迭代，applicationService层开始有很多业务封装逻辑，原因是原有的单个service层接口无法满足需求，需要对多个service服务的接口进行封装（编排），这就导致applicationService变得越来越重。

那么怎么解决呢？

首先认证权限校验功能，access_log，异常统一处理 基本不带业务逻辑，是不是可以单独抽离出一个门面服务。

那么原有的applicationService就只剩下了参数校验，数据封装，和业务封装逻辑；对于业务封装逻辑，是不是可以下沉到某个service服务；

比如，下订单接口，仅需要创建订单，扣减库存；这就涉及到两个服务（订单服务，库存服务），就可以完全把封装（编排）逻辑写在订单服务内；

如果可以的话，这样applicationService就只剩下参数校验，数据封装；

2. 隐藏逻辑

    一般我们服务中为了获取当前登录人信息，都会有个UserContext或者SessionUtils之类的。但是在分布式服务中，session无法共享；当时为了实现下游服务也能便捷的获取当前登录用户信息，便用dubbo的隐式传参，在每次dubbo调用中都携带上登录用户id；这样就可以在一些业务逻辑中，将creator info 或者updator info直接通过共享session的方式写入，甚至可以进一步抽取，在每一次create update 操作时，都直接将用户数据写入，这样写业务逻辑的时候就不用特意记着去赋值更新creator info 和 updator info了；


    但是我现在又在思考，service服务层，是否能包含这样的隐式逻辑，是不是应该将当前登录人显式的在参数里传入会比较好