＜实现领域驱动设计＞读书笔记

前言

我作为程序员已经参与工作多年了, 从刚入门开始就被java的Controller Service Dao 三层的模式所支配. 刚开始也认为这三层的模式很好, 把视图, 业务, 持久化三层分开, 是一个很好的开发架构, 但是随着中间工作的变动, 参与的项目的变多, 我深切的感受到这个架构工作中的不便之处.

简单的项目

1. 业务关系直接就在数据库表关系之间就直接实现了, Service Controller 就只有简单的一行, 取个数据给前端就可以, 感觉Service就是多余的.
2. 一些简单的处理可以直接放在前端做, 要不是用户浏览器端的不可信任的特点, 可以直接不要中间的server层, 浏览器直接连接数据库就可以. 基于这个特点 有很多的代码生成工具, 只要设计好表关系, 直接给你自动生成Controller和Service类

复杂的项目

1. 各种 Service类之间互相交叉引用, 同一个业务的两个方法分散在不同的Service类中.
2. 重复代码多, 由于上一步的交叉引用关系, 难以理清. 有新需求来了后, 开发者很倾向于重新写一遍业务方法, 导致重复代码多, 改动麻烦
3. 查找问题困难, 出现一个bug的时候, 不能根据bug出现的功能模块定位代码位置, 必须根据出现问题的接口来一步步反推找到问题的代码. 有时候找着找着就会发现原来还有一个放在在这个Service类中;
   比如: 用户反馈登录不上去, 你先找到登录接口, 根据登录接口的调用逻辑来 找到用户Service, 角色Service, 权限Service, 并且这些Service分散在不同的包中, 问题难以排查.

感受

虽然java是一种面向对象的设计语言, 但是关于Controller Service Dao 三层贫血模型实际就是面向过程开发方式, 面向对象最重要的是类, 而类是由属性和方法组成的, 贫血模型中DO是只有属性没有方法(Set和Get不算) , Service又是只剩下方法没有属性(近似无), 整个流程就是一个个方法之间的调用, 与面向过程编程类似. 完全没有发现面向对象的强大能力.

领域驱动设计

应该不止我一人有这样的感受, 当我了解到DDD后, 感觉DDD就是解决以上问题的, 并且是为了更好的使用面向对象的思想一种方式, 是打破传统的一个新的设计方式, 于是我决定拜读相关的书籍, 并且记录读书感想和笔记,

我选择的是下面这边书籍. 并且计划把读书感想记录在接下来的博客中