今天一直在坐火车，一直在想以前很多大佬关于DDD的分析与拆解的文章，说实话光是其中比如限界上下文，子域，聚合根等等，这些抽象的术语就像拦路虎一样去了解DDD，真的想起来mvc，mvvc是多么容易让人理解呀，那真是个十分和谐且愉快的学习过程呢。
好了，扯远了，首先我们都知道衡量代码写的好不好，复用性和内聚性是不可或缺的评价因素。同样这两个指标也是指导代码能力下沉的关键指标。大家肯定都会说这两个指标都滚瓜乱熟了，但是我觉得当团队的技术框架都成熟了，代码形成了定式之后成员很难发现这个问题。比如大多数业务执行用户请求的时候都会判断用户存不存在，所以service会调用user的服务（这里去调用微服务还是通过dao实现都可以，不影响描述）根据user的返回来判断，那是不是用户操作的所有业务这里都会这样判断，其实这里我们就可以把判断用户存不存在直接下沉到user这个model去做，业务方拿到user这个实体，直接user.isExist（）方法就能判断，语义非常清楚，是不是也有了点领域边界的味道？当然很多同学会说我们就是这么做的，这里只是举个例子，就是如果能保持对每个模型层的判断都如此简洁复用的话代码本身会清爽很多。
思考一下，复用性和内聚性在上面这个例子里面的本质是什么呢？实际上复用性告诉我们是什么时候该下沉，而内聚性告诉我们我们下沉到哪里。功能有没有内聚到恰当的实体上，有没有内聚到合适的层次上也是有两个层次的
所以不难发现我们通过这种循序渐进的能力下沉策略应该是一种更符合实际，更敏捷的方法，因为我们需要承认模型不是一次设计出来的，而是迭代演化出来的。
我必须承认我并不知道上面描述了什么，看起来就是一个简单的代码下沉，但对我自己来说我却感觉仿佛有很大收获似的，希望以后能多些这样独立的思考。
