领域驱动设计

 

不知为啥，豆瓣9.4号至10月3号不让写评论了，是为了国庆吗。 读后感就写这儿吧。这本书个人感觉需要参与过多个项目，踩过很多坑的人读，或者你有幸参与到一个严格坚持领域驱动开发的团队当中通常是外企进行学习过。书中概念过于抽象，但确实是解决软件复杂度的必备良药。现在我只是粗读，而要达到理解运用还需要再日常开发中多多的训练，自觉不自觉的往这些规则上套，或者已有的系统采用了里面的哪些规则。

 

1. 自己也要学着话这种模型图，模型图代表着技术人员和领域专业人员对需求有这清晰的定义，然后软件的设计需要体现这种模型， 最后代码的实现要清晰的把设计体现出来，这三层是缺一不可。

 

2. 领域模型和代码都是在不断变化和修正的，其中任何一方发生改变，都要及时的反映在另一方身上。

 

3.service采用协议来进行通信，协议可扩展

 

 

 

4. 在微观的角度，作者从最底层开始构建这样的一个4统一（ 沟通，模型，架构，代码）的角度来开始构建这样的模型。 软件分层，避免一个大铁锤系统；UI， 业务逻辑，persistence 层。 三者之间隔离， 用Service 讲UI和model 通讯，用Depository 将存储与模型分离。 突出软件最核心的不是UI，不是存储（数据库）， 是业务模型。

6.软件开发复杂性的根本原因是问题领域本身错综复杂，控制复杂性的关键是有一个好的领域模型，此模型不应该仅仅停留在领域的表面，而是要透过表象抓住领域的实质结构，从而为软件开发人员提供他们所需的支持，

7.开发人员之间对话，领域专家之间讨论，以及代码本身表达，都应该基于同一种语言，来自一个共享的领域模型

8.不能把模型仅仅作为理解工具，而应该严格按基础模型编写代码。模型驱动设计寻求分析和设计的合一，程序设计，以至代码本身，都与模型密不可分。

9.由于领域模型的重要性，需要有意识的将领域对象与系统中其他对象分离，开发者借助各种各领域基础模型（实体「Entity」，值对象「Value Object」，服务「Service」，包「Package」等）以及各种领域对象生命周期管理策略（聚合「Aggregate」，工厂「Factory」，存储库「Repository」等）来消除模型和现实间的鸿沟

10.模型的构建不可能一步到位，真正强大的领域模型是随着时间演讲的，即使是最有经验的建模人员也往往发现他们是在系统的初始版本完成之后才有了最好的想法。－－理解的逐步深入，重构的必然与重构的方向

11.隐式概念的挖掘办法：倾听语言；检查不足之处；思考矛盾之处；查阅书籍；不要固执己见，尝试，再尝试！

12.可建模概念的种类：经常被领域专家提及的－－事物、行为、约束、过程。

13.模型构建的逐步深入导致重构不可避免，所以提倡柔性设计：设计必须要让人们乐于使用，并且易于做出修改。各种常用柔性设计模式。

14.如何在复杂系统，多团队下实现模型驱动目标的三大基本原则
   上下文：子模型的边界及转换
   精炼：关注对模型核心的持续提炼
   大比例结构：总指导原则