大话DDD

DDD (Domain Driven Design) 领域驱动设计

这个概念很多年了，书也很多，面试的也多。但是落地的少

要了解DDD 我们那其他的概念一起看
TDD （Test Driven Development） 【英文不重要，反正都是弟弟】
敏捷开发

敏捷开发先有需求，再制作原型去和业务解释，然后再拿着原型去和开发解释，开发拿到原型后进行设计开发

TDD 用测试用例去驱动开发设计
DDD 领域驱动设计

领域驱动里面有一个概念，最小单位是领域，就好像面向对象中的万事万物皆对象，万事万物皆领域。

DDD中有几个关键的概念 ，聚合根，贫血模式，充血模式，领域服务
聚合根：每个领域都可以理解为一个对象，任何领域的动作都应该由对象作为主体发起，就好比树形结构，任何树形结构都是从root发起的，这就是聚合根，你也可以理解为就是面向对象的对象。

就好比一只鸟有翅膀，尾巴，头部等领域，如果每个领域独立出来都不合理，只有在一起的时候才可以合并成鸟

这个对象中如果只有属性，没有动作我们称为贫血模式
如果既有属性又有动作，我们称为充血模式

我们用程序举个例子

比如我们要设计人喝水这么一个功能

一般mvc场景下我们都是先设计一个drinkService ，里面有一个drink方法，入参可以是人[person]
我们谁要喝水，传入需要喝水那个person就好了，如果你和我要喝水，
drinkService 里面 调用 drink(你，我) 就可以了

但是从领域驱动上来说这是不对的。需要在person这个类上加上喝水这个动作。
因为任何动作都是需要主体的。
那这个设计就变成person 类上有drink 方法
那按照领域驱动的设计 drinkService 需要调用 你.drink() ,我.drink()
来完成你我喝水的动作

mvc 版
person 类 贫血模式

public class Person {
    public String name;
    public int age;

    public Person(int age,String name){
        this.age = age;
        this.name = name;
    }
}

drinkService

public class DrinkService {

    public void togetherDrink(){
        Person you = new Person(35,"peter");
        Person me = new Person(26,"sally");
        drink(you);
        drink(me);
    }

    public void drink(Person person) {
        System.out.println(person.name + " "+ person.age + " drink");
    }
}

DDD版
Person 类 充血模式

public class Person {
    public String name;
    public int age;

    public Person(int age,String name){
        this.age = age;
        this.name = name;
    }

    public void drink(){
        System.out.println(name +" "+age+" drink");
    }
}

DoDrinkService

public class DoDrinkService {
    public void togetherDrink() {
        Domain domain = new Domain();
        domain.drink();
    }
}

Domain

public class Domain {
    public void drink(){
        Person me = new Person(26,"sally");
        me.drink();
        Person you = new Person(35, "peter");
        you.drink();
    }
}

可以看到DDD版中drink的动作在PERSON 类中，service中已经没有drink
这就是充血模式

如果一个service 中有多个领域需要组合使用来完成某个功能就叫做 领域服务

分层架构：UI层、应用层、领域层、基础设施层；

User Interface
负责向用户展现信息，并且会解析用户行为，即常说的展现层。
Application Layer
应用层没有任何的业务逻辑代码，它很简单，它主要为程序提供任务处理。
Domain Layer
这一层包含有关领域的信息，是业务的核心，领域模型的状态都直接或间接（持久化至数据库）存储在这一层。
Infrastructure Layer
为其他层提供底层依赖操作。
层结构的划分是很有必要的，只有清晰的结构，那么最终的领域设计才宜用，比如用户要预定航班，向Application Layer的service发起请求，而后Domain Layler从Infrastructure Layer获取领域对象，校验通过后会更新用户状态，最后再次通过Infratructure Layer持久化到数据库中。