初探领域驱动设计（DDD）part 1

写在前面

总结一下自己的皮毛感悟：
　　初次听说这个概念，于是产生了一些好奇，在阅读《领域驱动设计》前一章之后总觉得很多概念有点虚无缥缈，一方面可能是自己头一次接触这种类型的概念，另一方面就是自己的知识储备量不足，还没有达到能够轻松了解的级别，但是有一点是可以确定的，就是平滑的学习路线应该在我对设计模式有充足了解，对项目架构有了自己的思路以后，领域驱动设计会成为点醒我的另一个途径。
　　作为一个早在2003年就被提出的概念，所以说这其实并不是一个最近兴起的事物，从另一个角度来说，它是经历过时间沉积，历久弥新的设计方法。前端技术几十年来一路上产生了许许多多的变化和发展，借用阮一峰老师曾经的点评：

前端变化有多快?两年前，大家都用Grunt构建，去年用Gulp + Browserify构建，今年用Webpack构建，明年可能会使用纯ES6的构建工具。每变一次，前面的那些工具就全没用，都白学。要知道，这些工具每一个都是软件系统，单单Grunt就有4千个插件，然而全没用了。

所以不能抱着一项技术啃到死的想法来对待这份工作（虽然我连一个可以用到死的技术都没有怎么掌握）。

问题

不管任何一项技术或者思想的问世和了解，都需要从问题入手再谈用法：

• 为什么有的项目要采用DDD设计方式？
• 我该如何维护基于这种设计模式构建的代码？
• 我该如何参与该模式的项目设计？
• 如何将已有的项目或者不太符合的代码进行封装和改进？

感悟

我其实不太喜欢有些文章过多的发明名词的做法，虽然我自己写论文的时候有这种臭毛病，碍于字数和内容的要求不断的对已有概念进行糅合并美其名曰创新，然后下一个晦涩难懂的定义，套上一个高大新颖的名称，但是每次读到别人这样写出来的文章我还是很讨厌，所以站在一个读者的角度就知道自己写的东西到底有难读……
　　虽然这本书中也充斥着各类概念，但是我还是决定抱着啃下来的决心读一读，不过实在难以入门，我就在网上到处查阅资料，看过来人是怎么看待的，有一定基础再去读的话，想必不会一知半解，就像现在再刷红宝书一样，晦涩的知识反而能在现在让我不仅能轻松读懂，还能够举一反三。
　　定义:在DDD 里,DP可以说是一切模型、方法、架构的基础。它是在特定领域、拥有精准定义、可以自我验证、拥有行为的对象。可以认为是领域的最小组成部分。
　　
DP三条原则:

• 让隐性的概念显性化
• 让隐性的上下文显性化
• 封装多对象行为

“领域”，有的前辈将其解释为“业务问题的范畴”，就是说将一个整体的大型业务问题推演和抽象成多个内聚的部分，有点类似于分治思想和模块化、微服务，但是又不完全是，模块化、微服务是遵循解耦的原则去降低整个项目开发的维护成本和二次开发复杂度。DDD具体化举例到某一个业务来说可以解决这几个问题：

• 1．接口语义明确，可拓展性强，最好带有自检性
• 2．参数校验逻辑复用，内聚（核心业务逻辑清晰度）
• 3．参数校验异常和业务逻辑异常解耦（单元测试可行性）

针对第一条来说，以前的我可能感受不怎么强烈，但是回想起在实习的过程中用typescript开发业务时，感悟就来了，曾经写的代码因为对TS不熟练，要完成业务功能需求，所以总喜欢就写JS代码（弱类型），除非碰见前辈们已经定义了的类型，我轻易不会自己去自定义类型，虽然说暂时站在前辈的肩膀上，实习工作并不需要我去自定义类型（也不能轻易去更改）但是后期如果要自己担任某个业务的owner，理解这种做法是必不可少，不然屎山堆高了自己都处理不了。但是想要接口语义明确，可拓展性强，最好带有自检性，TS确实可以通过自定义类型进行类型校验，避免了类似乱传参的低级错误。
　　第二条就更好理解了，业务必须要进行拆分，什么业务解决什么问题，要保持纯粹和单一，例如一个button的功能是播放一段动画，但是要拿从后端请求的参数进行匹配，播放不同动画，显然匹配逻辑和播放逻辑就不适合写在一起，什么逻辑就应该归属于什么业务域。我以前在迭代某些业务的时候喜欢用一些小逻辑，或者三元表达式简单快速的搞定，后来codereview的时候被老大提醒了，这种方式可读性太差了，还是将不同的逻辑部分抽离，然后再进行判断。而且抽象的时候要注意相关逻辑的抽象和聚合，这里用一个大佬的举例：手机号归属地查询和手机号运营商查询的逻辑都是手机号的属性，内聚在手机号类型中就再合适不过了，这和设计模式中的命令模式有点相似。
　　完成了以上两点，那第三点其实就不攻自破了，在对业务逻辑简化后，进行单元测试的难度其实也大大降低了。
　　我觉得这里实际上就是对面向对象设计的一种概括，当然DDD肯定不止这些，写到这里也只是我自己的一些领悟皮毛，不过我刚好下一章该做红宝书面向对象章节的阅读了，趁热打铁吧！

感谢寒食君的视频，然后附上一篇比较好的博客：传送门