DDD领域驱动设计和微服务

问题：

   1.你的代码真的是面向对象编程吗？还是面向上帝编程

   2.微服务解决了哪些问题？遗留了哪些问题

一 面向对象编程VS面向数据编程

       首先想一想我们平时开发的流程 拿到产品设计之后 首先是不是进行表设计，这个流程对吗？如果上来就是设计表，创建实体类和表进行映射，那么这到底是面向数据编程 还是面向对象编程，可能说到这，有些人还是不明白，就比如说下单这个流程 

public class orderServiceImpl{

   public void  creatOrder(){
  
      //减库存
      ....
     //创建订单
   }

}

这是一段伪代码 这里减库存这个动作 里面是不是还有判断商品库存够不到 等一系列操作，问题到这，大家想一想这是面向对象操作吗？有人可能会说是呀 面向的对象是orderServiceImpl,这样说没毛病，那这里orderServiceImpl是不是就相当于上帝对象，它可以干所有的事。为啥这样说  大家想一想减库存 判断商品库存这是谁的事情，是商品这个对象的事  怎么就成了orderServiceImpl的事情了呢？换句话说 这段代码 我是不是放在任何一个service层都可以。那所谓的面向对象到底面向的是哪个对象，而我们商品对象里面 是不是只有一些属性和get set方法，当然专业一点的可能说这是贫血模式，对应的就是充血模式，那什么是充血模式，充血模式就是这个对象除了一些属性和get set方法，还包含一些对象的功能方法，就比如说商品对象，这里面应该还包含商品减库存的方法。

贫血模式

@Data
public class StudentCourse {

    private Long id;

    private Long studentId;

    private Long courseId;
    
}

充血模式 

@Data
public class Student {

    private long id;

    private String name;

    private String phone;

    private List items = Lists.newArrayList();

    public Student(long id) {
        this.id = id;
    }

    public Student() {
    }

    public StudentCourse xuanke(Long courseId){
        StudentCourse studentCourse = new StudentCourse();
        studentCourse.setCourseId(courseId);
        studentCourse.setStudentId(this.id);
       return studentCourse;
    }
}

二 微服务和DDD领域驱动设计

        微服务的出现解决了项目的臃肿，服务可以独立的开发、测试、构建和部署。但是问题是怎么去划分微服务，你怎么能保证你划分的微服务就是最合适的，如果拆分后的服务出现互相调用或者需要高成本解决各个服务间的数据一致性，将得不偿失。DDD个人理解就是把业务再进行细分每个领域做自己的事情，各个领域之间互不干涉，互不影响，各司其职，他们之间可以通过领域服务，站在程序员的角度来看就是大部分业务逻辑都封装在自己的对象里面，如果一个业务设计到多个领域就把封装一个领域服务来处理。

我们看看DDD领域驱动设计

1、 展现层
展现层负责向用户显示信息和解释用户指令。
2、应用层服务
应用层是很瘦的一层，其服务主要用来表述应用和用户行为。它主要负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装，拼装完领域服务后以粗粒度的服务通过API网关向前台应用发布。通过这样一种方式，隐藏了领域层的复杂性及其内部实现机制。 应用层除了定义应用服务之外，在这层还可以进行安全认证，权限校验，持久化事务控制或向其他系统发送基于事件的消息通知。
3、领域层服务
领域层是较“胖”的一层，它实现了全部业务逻辑并且通过各种校验手段保证业务正确性。业务逻辑包括：业务流程、业务策略、业务规则、完整性约束等。 当领域中的某个操作过程或转换过程不是实体或值对象的职责时，便将该操作放在一个单独的服务接口中，这就是领域服务，领域服务是无状态的。
4、基础设施层服务
基础设施层服务位于基础设施层，根据依赖倒置原则，封装基础资源服务，实现资源层与应用层和领域层的调用依赖反转，为应用层和领域层提供基础资源服务（如数据库、缓存等基础资源），实现各层的解耦，降低外部资源的变化对核心业务逻辑的影响。
5、总结
应用层服务是展现层和领域层的桥梁，通过调用领域对象和领域层服务来表达用例和用户故事。领域对象负责单一操作， 领域层服务用于协调多个领域对象共同完成某个业务操作。 应用服务原则上不处理业务逻辑，领域服务处理业务逻辑。
 

在这种设计下，各个领域模型在一个个有界上下文中发挥其作用，完成用户要求的功能，从而降低或隐藏业务复杂性，使系统有更好的扩展性。

   

 参考：领域驱动设计(DDD)及微服务_王卫东 博客-CSDN博客_领域驱动设计与微服务