DDD初步了解
DDD：Domain Driven Design，领域驱动设计，随着微服务的流行，业务的快速发展（变化+复杂），团队的迅速膨胀，DDD也被越来越多的公司使用。
拆分领域模型，使用充血模式（与贫血模式相反，我们MVC模式中的model/DO/DTO，只包含属性和get、set方法，就是贫血模式）；
各领域独立发展，领域间的交互，使用领域服务来实现；
封装变化；
实现功能时，要通过防腐层来封装变化，这样业务功能不变化，该功能就不会变化（变化的是防腐层里的实现）；
以下记录了马士兵DDD公开课中，通过一个选课系统，比较领域驱动设计与MVC实现的不同：
- 业务逻辑清晰度，业务人员也可以阅读；
- 业务稳定性，业务不变，代码也不动；
- 防腐层隔离变化；
- 贫血模型vs充血模型：Student贫血模型，会被各种Service调用，选课、借书、体育......，会分布在不同的业务中，你还敢随便改Student信息吗？除非你读懂每一个Service的调用过程！改成充血模型，加入upgrade()、run()等和自身状态相关的业务逻辑，每个实体操作自己实体的变化，跨实体的变化，通过领域服务搞定，领域服务调用实体方法完成状态改变。
- 各领域内自治，可以自我发展；
- 用仓库StudentReponsitory来管理Student的存储；
- 仓库中集成工厂Factory/Builder应对复杂对象的组装；
- MVC保证了实现最差也差不到哪里去（但基本总是最差），DDD如果做得差，会比MVC还要差，如果做的好，的确可以应对业务的变化（了解业务，预测业务的变化-这个比较难，所以DDD做好也很难）。
