读《阿里高级技术专家方法论：如何写复杂业务代码？》的感想
作者：
可爱猪猪-帅锅一枚
作者的网名很阔爱，如果喜欢本文章一定要点 喜欢 或者 打赏，拜托~
作者一直在进步，需要你们的支持和鼓励，谢谢!
人生理想：在程序猿界混出点名堂！
原文地址：https://mp.weixin.qq.com/s/pdjlf9I73sXDr30t-5KewA
如何写复杂业务代码？作者讲的几个点，在这里做一下笔记，还有以后可以加深自己对哪些方面的知识进行涉入，做一下记录。
好了，说一下从这边文章的收获：
1. KISS（Keep It Simple and Stupid）
这个是apache的一个设计原则，开发一个业务或者技术，使他简单到愚蠢的人都可以看懂。
每个人在开发的过程中都期望如此，然而在开发业务代码的时候，要做的简单并不一定要引入各种工具、设计模式，其实80%的业务代码，只需要按照类似写PPT的思路来写就可以了，先写目录-每个章节写标题-每个标题写内容，将问题分解和抽象，形成一个金字塔，例如作者分解：
问题分解.jpg
代码示例：
@Command
public class OnSaleNormalItemCmdExe {
@Resource
private OnSaleContextInitPhase onSaleContextInitPhase;
@Resource
private OnSaleDataCheckPhase onSaleDataCheckPhase;
@Resource
private OnSaleProcessPhase onSaleProcessPhase;
@Override
public Response execute(OnSaleNormalItemCmd cmd) {
OnSaleContext onSaleContext = init(cmd);
checkData(onSaleContext);
process(onSaleContext);
return Response.buildSuccess();
}
private OnSaleContext init(OnSaleNormalItemCmd cmd) {
return onSaleContextInitPhase.init(cmd);
}
private void checkData(OnSaleContext onSaleContext) {
onSaleDataCheckPhase.check(onSaleContext);
}
private void process(OnSaleContext onSaleContext) {
onSaleProcessPhase.process(onSaleContext);
}
}
2.分解代码残留的两个问题
- 领域知识被割裂肢解
引用作者原话：“什么叫被肢解？因为我们到目前为止做的都是过程化拆解，导致没有一个聚合领域知识的地方。每个Use Case的代码只关心自己的处理流程，知识没有沉淀。
相同的业务逻辑会在多个Use Case中被重复实现，导致代码重复度高，即使有复用，最多也就是抽取一个util，代码对业务语义的表达能力很弱，从而影响代码的可读性和可理解性。”
什么意思呢？相同的逻辑被分散在各个处理流程里面，这就要求将重复代码抽象、层次划分和层次约定，约定好哪个层次是做什么，什么逻辑应该抽象在层次中，这也许就是后面作者介绍的领域模型，有空要体会一下
- 代码的业务表达能力缺失
引用作者原话：“试想下，在过程式的代码中，所做的事情无外乎就是取数据--做计算--存数据，在这种情况下，要如何通过代码显性化的表达我们的业务呢？说实话，很难做到，因为我们缺失了模型，以及模型之间的关系脱离模型的业务表达，是缺少韵律和灵魂的”
感想:用业务逻辑来表达技术逻辑
比如
// 技术逻辑
public void doBiz(){
ProduceCenter pc;
if(pc.produces.size() ==0 ){
throw new BizException('库存中心没有商品，请稍后重试！');
}
....
}
public void doBiz(){
ProduceCenter pc;
if(isNoProducesInCenter(pc)){
throw new BizException('库存中心没有商品，请稍后重试！');
}
....
}
private boolean isNoProducesInCenter( ProduceCenter pc){
return pc.produces.size() ==0;
}
3.聊一聊作者所说的"能力下沉"
能力下沉：这个概念读了几遍才理解作者表达的意思
看下作者的原话：“所谓的能力下沉，是指我们不强求一次就能设计出Domain的能力，也不需要强制要求把所有的业务功能都放到Domain层，而是采用实用主义的态度，即只对那些需要在多个场景中需要被复用的能力进行抽象下沉，而不需要复用的，就暂时放在App层的Use Case里就好了。
通过实践，我发现这种循序渐进的能力下沉策略，应该是一种更符合实际、更敏捷的方法。因为我们承认模型不是一次性设计出来的，而是迭代演化出来的。”
我的理解编写逻辑代码，刚开始逻辑可能都写在一个类甚至是一个方法中，随着迭代的演进，将逻辑从方法中抽象，将可复用的方法写到对应的分层或者父类中，将逻辑慢慢的沉入到通用的地方，更好的复用代码，个人觉得对于抽象或者要复用的代码一定要抽象到一个约定俗成的地方，以免即使你抽象了，别人也不知道是否这个抽象的逻辑是否存在。这一点很重要在一个大型产品的开发中
4.另外作者推荐的几本书还有架构空的时候可以看一下
《架构整洁之道》
《领域驱动设计》
领域模式可以百度一下
COLA（作者写的可乐架构学习下）
