关于“编程的本质”的探讨
提出问题
如果你去面试，被大公司工作20年的资深技术总监问一个问题“说说你对软件工程的理解”，你会怎么回答呢？是不是会像我一样一脸懵逼，一个问题就让人回到了小学。没有经年的编程和架构经历，没有对问题本质的深入探究，恐怕任何回答都会显得非常苍白。
探索历程之编程本质
有了问题和好奇心之后，令你印象深刻的问题就会在一段时间内充斥你的脑海。让我回答对软件工程的理解，可能我会先从“软件工程”的定义说起，他应该是一个一级学科，下面包含的范围非常广泛，比如计算机科学、光电信息工程、媒体信息工程、自动化控制、通信工程等。
我自己比较熟悉的是计算机科学相关，而计算机科学又是包罗万象，日常工作可归之为“编程”一类，写的业务代码居多，中间件和架构也占一部分。
拿自己熟悉的编程来说，问题就变成了“什么才是编程的本质”，我如果把这个问题回答好了，以点破面，也算是能勉强回答总监提出的问题了。
那么什么是编程的本质呢，看到左耳听风的一篇专栏文章（强烈推荐耗子大神，专栏地址），大致观点如下：
编程 = 算法 + 数据
算法 = 逻辑 + 控制
用图来表示：
如果对一个表单做验证，用逻辑+控制的思想，可以这么写：
var meta_create_user = {
form_id : 'create_user',
fields : [
{ id : 'name', type : 'text', min_length : 3 },
{ id : 'password', type : 'password', min_length : 8 },
{ id : 'repeat-password', type : 'password', min_length : 8 },
{ id : 'email', type : 'email' }
]
};
var r = check_form(meta_create_user);
上面meta_create_user是“要做什么”，也就是逻辑。下面check_form是“怎么做”，也就是控制。
这个观点对我有非常大的启发，引发了我很多思考。
探索历程之架构设计
根据上面的观点，那么在架构设计层面，逻辑+控制的思路能否行得通呢？
正好我最近被另一个问题困扰，那就是随着业务的复杂，架构如何才能不僵化？比如一个企业服务CRM系统，多租户、多业务线，而且业务线之间耦合还非常重，随着业务线的增多，代码开始变得错综复杂，无数线头纠缠在一起，剪不断、理还乱。再把多租户考虑进去，就相当于在线头上又掉上了油漆。
老人扎进了修复bug的海洋，新人理不清业务线。出现这种情况，问题源头也好找：架构没做好。
可是架构怎么做？面向对象的五大原则（SOLID，即单一职责原则，开闭原则，里氏替换原则，接口隔离原则和依赖倒置原则）说起来头头是道，设计模式用起来得心应手，SOA的理念烂熟于心，分层的思想也面面俱到。还能要求架构师什么呢？
虽然很委屈，但也很焦急。
人找不到答案的时候，往往是视野出了问题，也就是视野太窄造成困于原地。
放出去看看业界有什么样的解决方案么？那些聪明勤奋的人恐怕早遇到过这样的问题。
还真被我找到了，这就是领域驱动设计，简称DDD。这种思想简直让我大开脑洞，印象最深刻的有两点：1、程序员要深入了解业务，了解业务之后建模；2、建模是构建一种共同的语言，这种语言架构师、领域专家、产品经理都能看得懂，而且就用这套语言沟通并一起完善它。
这种思想好啊，熟知领域知识说不定还能在代码层面进行微创新，真是振奋人心。
有了纲领，就是有了方向，接下来要考虑的就是怎么在编程层面的落实了。
还是老办法，这个思想出来了这么久，肯定有聪明人做过落实的这个事儿啊，何不参考之？麻烦就麻烦在有很多人做了实现，但开源的却太少。
在Github上找一找，真发现了一个阿里同学写的框架：https://github.com/alibaba/COPA
看过他的设计和博客文章后，也是惊为天人，非常感谢significantfrank的分享！
探索历程之融合
如果你和我有一样的困扰，建议你认真看一下COPA的理念。
接下来我们再来看领域驱动设计和逻辑+控制之间存在什么关系呢？
其实想要践行DDD，必然要熟练的应用到很多设计模式，我们以设计模式中比较经典的策略模式来看一下他们之间的关系，比如一个商品优惠的策略：
有三种优惠方式，分别是普通打折（比如9折），满减，期限内的特价。我们看到Strategy下的三个实现就是逻辑，而Context的组合拼装就是控制。
策略模式比较简单，回到领域建模，在COPA框架中分了三层，其中Service Facade可以看成是控制，Domain里都是逻辑，Infrastructure里则是数据了。现在再来看，从微观到宏观，编程 = 算法 + 数据 ，算法 = 逻辑 + 控制 这种思想可谓是历久弥新！
