年初的三个FLAG已经完成了两个：[聊聊面向服务的架构]，[元数据驱动的SAAS架构]，这是最后一个FLAG，本来打算业务建模的内容，但是列完提纲后，感觉意犹未尽，还是觉的把自己最想写的内容以完整且成体系化的方式呈现出来，所以就有了一个完整系列的提纲，内容比较多，不知道何时码完，但是必须把FLAG立出来，作为一个督促，提纲和整体思路也有一两年的历史了，也不能等了，打算以连载的方式慢慢攒吧，希望看官勿怪。

在这个快速奔跑，快节奏的年代，大家倾向于快餐式的汲取营养，喜欢小而短，没人愿意花时间看长文，为啥还要长篇大论，本系列不是提供离散的几个知识点或者几个特定场景的解题思路，而是试图建立一种体系化的架构师知识体系和思维体系，便于愿意深入思考的同道人进行交流碰撞，不会让大家失望和浪费时间。但是如果亲连引子认真看完的时间都没有，或者看完引子没有感觉，就不建议阅读了，免得浪费亲的时间，如果觉得有那么点意思，可以在评论区谈些想法或者点个赞，以便我获得相应反馈，并及时更新。。

目录

引子Prologue

一、如何认识客观世界—本体、逻辑与系统 @ToDo

二、认识与解构业务之建模—九宫格与价值流 @ToDo

三、业务建模之实体建模—亚里士多德 @ToDo

四、业务建模之业务对象—老子与爱因斯坦 @ToDo

五、业务建模之业务流程—抉择与颗粒度 @ToDo

六、业务建模之决策与规则— 一变应万变 @ToDo

七、回头看架构—架构起源 @ToDo

八、TOGAF与元模型（Metamodel） @ToDo

九、TOGAF之架构设计 @ToDo

十、系统架构之应用架构—乐高LEGO Blocks @ToDo

十一、系统架构之数据架构—关系与对象 @ToDo

十二、服务化架构—业务的本源 @ToDo

十三、我所理解的DDD—没有银弹(No Silver Bullet) @ToDo

十四、微服务与DDD @ToDo

十五、元数据驱动的SAAS架构

十六、架构之外—Object Oriented,我们真的理解面向对象了吗？ @ToDo

十七、架构之外—一专多能，深度决定高度，广度决定圈子 @ToDo

十八、架构之外—Scrum敏捷开发与项目管理 @ToDo

十九、如何成为更好的自己？我的思考— 未来真正稀缺的是具有成长心态且能有体系化独立思考的跨域人才

二十、我的反思

后记Epilogue—敢问路在何方？

引子 Prolog

He who cannot draw on three thousand years is living from hand to mouth.

— GOETHE

 

The soul of man can never be enslaved

Save by its own infirmities

nor freed

Save by its very strength and own resolve

And constant vision and supreme endeavor!

— Francois Fenelon

Keep your eyes on the stars, and your feet on the ground.

— Theodore Roosevelt

致虚极，守静笃。万物并作，吾以观复。夫物芸芸，各复归其根。

— 老子

Education is not the learning of facts, but the training of the mind to think

— Albert Einstein

“你未来3-5年想要做什么，你想在聚焦在哪一个方向做深做透，技术、架构抑或业务解决方案方向，你想要成为一个什么样的人？”，这是过去几年内我最爱追问自己和曾经团队技术小伙伴的同一个问题。但这个问题从来没有如此强烈的迫切感，直到我决定给儿子进行英语启蒙的那个小学三年级前的那个暑假。“到底我想引导我的孩子成为什么样的人，具有什么样的Character or Quality呢？”，面对孩子，这个问题异常严肃且现实，从那时起一直让我诚惶诚恐，忐忑不安，尽最大努力尝试去寻找时间缝隙去阅读中外文经史哲，从我们老祖宗的“内用黄老，外示儒术”到康德的Starry Night，罗斯福的“仰望星空，脚踏实地”，再到YouTube美国脑科与教育专家的Lecture，虽然不可能有明确的答案，但是收到的感悟越来越多，方向越来越收敛，逐渐变的清晰明确。

我记得在第一次百阿培训时候的天使送给了我一本原版书Everything I Never Told You（无言的告白），故事从一个小姑娘的失踪，死亡开始，情节非常压抑，整个阅读过程非常阴郁，硬着头皮读完，感觉像从一场抑郁症中恢复过来一样的，我原来只把它当成一个表述美国种族、身份认同、男女不平等和家庭危机的一个呐喊。但是书的cover上一句话一直萦绕于怀：All our life, we are about to get rid of the expectations of others to find the true self。

我们终此一生，就是要摆脱他人的期待，找到真正的自我。或许我们自己没办法做到，但是应该引导孩子拥有这样的机会，拥有选择的权利。我们是选择给予还是引导呢？给于他金钱，训练他的技能，教他阅读，教他一口流利的英文，数学技巧，写作技巧，考一个高的分数，还是引导他走一个不同的路呢？如果是引导，那么如何引导？

我们先来看下欧美的教育理念，当然欧美的教育未必是最优的，但是就像黑格尔的辩证法中的正、反、合（thesis,antithesis,synthesis）思想提倡的一样，即便是相反的东西也一定是可以借鉴的，融合的，可以取长补短的，形成更优的更先进的东西。欧美提倡三个核心的教育理念：

1. Reading Comprehension ：解码文字，微言大义，理解吸收观点并融合已知
2. Critical Thinking：批判式思维
3. Problem Solving：解决问题

个人理解本质上和阳明先生的”知行合一“有共通之处，Reading Comprehension 和Critical Thinking 在”知“中，Problem Solving在”行“内，知行统一，相互交融，相辅相成，我们在Reading Comprehension中吸收的内容丰富了我们的知识结构和系统，为Critical Thinking提供了理论或者事实参考，Critical Thinking为Problem Solving提供决策或者行动的内在逻辑和辩证分析判断，反过来呢，Problem Solving行动中的经验和教训既为Reading Comprehension 内容吸收提供体感，也为Critical Thinking提供了实践参考。

三个理念循环往复，相互促进，最终带给孩子最重要的东西是什么呢？亦或是什么品质，什么能力呢？

精炼一下，我想我目前能得到答案是，塑造和锻炼孩子的一个核心能力：独立思考。另外一个宝贵的获得：成长心态（growth mindset）,也极其重要，是不断突破个人天花板的极其宝贵的品质，暂先按下不表。

只有独立思考，才能不人云亦云，不上下盲从，在变化中寻找并分离不变，拥有笃定的研判，方能不随波逐流，不会落入乌合之众的陷阱，最终才能有选择的自由，找到真正的自我，独立的战略以及战术定力。

话题转回来，回到我们技术同学本身，我们来回顾下技术的世界：

• 作为一个业务架构师，对业务进行建模的时候，是一上来就跳到解决方案域（Solution Domain）或者更具体技术实现上，抓住业务场景的用例进行自行抽象，忙着区分名词、动词和形容词等等进行用例语法分析，快速创造出快餐式的实体模型或者对象模型？还是围着着问题域（Problem Domain），仔细思考、追溯并判断这些业务场景的源头是什么，隐含的业务问题到底是哪些，对应的业务本质是什么，从而基于业务场景和用例先对问题进行建模，把问题定义清楚呢？例如，无论零售业务的花样如何多变，消费的本质上还是人、货、场，基于此来分析这些业务场景到底隐含了那些问题，从人的角度，从货的角度，从场的角度等等；对供应链业务来说，这些业务场景背后要解决降本提效的问题，还是快速和商家协同通过新制造，快速C2B反向定制，创建新的销售机会呢？这些业务场景或者需求和供应链的核心指标之周转和缺货有直接关联吗？如果没有，那间接关系是什么？另外是否可以不要局限于你是开发、架构、产品抑或业务，跳出来从更宏大的角度来思考，一个商业抑或业务也是一个系统，从系统动力学的角度来看，系统最根本的目的就是生存和发展，是活下去还是要活的更好，对业务场景的思考和处理方式也不一样。抑或是否从九宫格的商业画布来延展开来思考呢？不要给自己设限，你的圈子、工作内容或者你的影响力也许有限制，但是没有人限制你的思考，也没有人能阻止了你的思考，作为技术同学，不要只把自己限制在技术领域，没有人限制你思考产品，思考业务，甚至思考商业逻辑，其实现实是你必须思考产品，思考业务，思考商业，你才能突破自己的天花板，只是你以为天花板是你的老板给设的，业务给限制的，组织给设定的，其实没有想到是自己给自己设的，我自己在一直在反思，我想我们大多数人都应该做到能独立思考，才能好好反思，释放出我们的growth mindset，把压在自己头顶的太多并不存在的Assumption去掉，为自己打开空间。
• 作为一个应用架构或者技术架构师，快速学习业界新的技术和框架是我们的本分，我们通常热衷于追逐各种新的技术潮流，新的技术，新的框架，特别是新的技术名词，那我们有没有想到技术的发展，架构的演进本质上同自然科学与社会科学的演进过程异曲同工，其不断演进的发展过程，尤其内在的严密的发展逻辑，即便是跳跃式的发展，必然有其长期的沉淀过程和矛盾不断积攒和逐渐激化才能爆发的过程，遵循着黑格尔的正反合不断演化发展的辩证法，比如我们现在AI的技术的爆发(个人认为目前还是一个Spike)其实很多核心理论的积累都是来源上世纪中后期，只不过当前基础算力和网络等基础设施的快速演进，结合当前互联网应用场景，提供了大量应用的空间。所以我们回头来看我们技术和应用架构设计，到底我们的架构设计是根植于我们对业务本质的生存和发展的理解而产生的对技术和应用架构的要求的深度思考、对于架构变与不变的归纳演绎抽象，以及我们对于技术、架构演进规律的研判，还是各种新潮技术、新潮框架和新潮名词的仓促堆叠？我想我们的内心深处会有一个清晰的判断。如果你是前者，请接收我的膝盖和膜拜，如果你是后者，当然你得直面内心，愿意认识到，那我想你需要从现在再开始考虑我有没有独立思考的能力，或者支撑我的独立思考的到底是什么？因为这个是一个本质的问题：如果你是一个架构师，它存在于你对架构的思考和设计上；如果你是一个TL，那同样存在对于人的判断，对人的敏感的过程中，以及如何进行排兵布阵，如何激发团队的每个人成为更好的自己的行动上；如果你是个项目经理，那它同样存在于包括设定项目范围，组建队伍，指定项目计划，掌控关键路径，识别风险，管理风险，管理交付，管理客户预期，以及果断决策的过程的方方面面。
• 作为一个开发同学(当然每个人都可以一专多能，原谅我分的这么细),我们每天使用Java面向对象的语言进行设计和开发，我们每天都在创建对象，添加对象属性，生成对象方法，用提炼接口来显示我们抽象能力，来满足业务日益增长的需求，当前主要矛盾变成了人民日益增长的业务产品需要同操蛋的面向对象（Ye Mian）开发生产效率之间的矛盾。但是我们码了那么多代码，创建了无数的对象类，但是有没有真正想过面向对象的中对象到底是什么含义？你的每一个Object这个Concept到底怎么来的呢？每个属性对这个对象到底意味着什么，对对象之外又意味着什么呢？对象的行为对于对象意味着什么？对象的行为来源哪里？行为和对象的属性之间有什么关联？很多对象都是一个系统，从系统理论来讲，系统的结构决定它的系统行为，这是不是对象属性和行为的一个可能的解释呢？我们通过面向对象系统搭建了各种应用，应用又组成了系统，根据系统理论，系统大于部分之和，那么我们怎么看待各域应用和整体端到端系统之间的关系呢？又给我们带来系统设计上的什么启发呢？技术同学中其中有一种小众现象，虽不普遍，但饶有趣，成长靠晋升，晋升靠系统重构，系统重构必谈DDD，DDD风行的程度搜下ATA就可见一斑，曾见过一个现象，从低到高起人人必谈DDD，有一种全民皆DDD的倾向，你不谈DDD好像就代表你抽象建模能力不够一样的，甚是奇怪。当然我并没有声讨DDD，也不是说DDD本身有多大的问题，而是你要把DDD本质是什么想清楚，构建自己的逻辑思考体系，然后再把它当成一种思想，一种框架，或者一种设计风格来应用，设计开发系统从来就没有银弹，DDD同样不是银弹。同时感觉在真正的DDD应用中，个人认为并没有把主要的精力放在对业务本质的抽象上，深挖业务对象的来源和本质，建立具有统一业务语义的域模型包括术语和词汇，更多的精力放在纠结在是不是贫血或者充血，领域服务怎么理解以及怎么做啊，防腐层放在哪，领域层、应用层怎么划分边界啊，对DDD中的层次划分讨论乐此不彼。

上面是既是对观察到的个别现象的剖析，也是对自我的剖析，因为自己曾经”不识庐山真面目，只缘身在此山中“。

重新回到到我们的设计开发过程中来，作为程序猿，我们之前曾经自己给自己开一个玩笑说天下代码一大抄，写代码基本靠借鉴(拷贝粘贴)，虽然是玩笑话，但是其中的自嘲意思大家都秒懂。天下武功唯破不快，大家都喜欢直奔主题，先解决问题，看了各种JDK，Spring等框架源码主要是为了应用(模仿)搞定问题，在这样的快节奏里面，缺少去读懂去琢磨透的耐心，往往下次遇到相同的情况，并没有领悟其背后的逻辑而举一反三去解决问题，而是再去借鉴一把（抄袭）。

我们的开发的看家本领—面向对象编程技能，其实有些时候是面向好像编程：这里好像需要增加个对象，其实并没有考虑到这个对象代表什么含义，反应了什么样业务或者设计本源；这里好像需要增加一个接口，就增加一个接口，并没有考虑这个接口的增加对整体服务意味着什么？和其他的接口的关系是什么？接口的增加会不会带来功能的一致性问题以及对数据一致性造成破坏?奥卡姆剃刀原理提到：如无必要，勿增实体，本质上并不是要我们减少实体或者对象，降低复杂度那么简单，而更重要的是要每一件事情的思考、判断以及决策的背后必须要有严密的逻辑支撑，而且这个逻辑起码经得起你自己的推敲，然后再要经得起其他人的推敲。

同样地，我们好像特别热衷画架构图，画了一遍又一遍，业务架构，应用架构，技术架构等等等等，满足不同的目的，有的是为了向上汇报的，有的是内部沟通的，不一而足。每个架构图的由于重点不一样而有一定的差异可以理解，但是通常情况下，本来是描述一个相同东西，但是每次的架构图有时间大相径庭，之间看不到任何逻辑上的延续性和相关性，有时候反倒是见怪不怪的现象了。我想其背后的原因也很清楚，所谓的架构设计和架构图要么是不合理的现状的拼凑，要么是好像驱动的架构设计，这些部分好像这样分层看上去合理，或者好像这么分层比较流行哎。这些架构设计必然没有基于体系化的去思考，也就没有成套的方法论去设计和验证,就必然不会有经得起推敲的逻辑。

老子曰：道生一，一生二，二生三，三生万物，里面的道理无穷，道可道，非常道，然而我们从其中却依然领悟到一个对我们具有实际启发意义的方面，称之为：道、法、术、器、势。

周易曰：”形而上者谓之道，形而下者谓之器“，我们先来看器和术。器，顾名思义，就是工具，暨”工欲善其事，必先利其器“提到的器，用以提高效率：具体到我们的软件开发过程中，器就是我们开发用的IDE，系统搭建过程需要用到的数据库，中间件以及各种容器；具体到我们架构设计过程中，器就是我们进行业务建模以及设计架构图等过程中用的各种工具软件等。术，指的具体的技能或者技术，我们掌握的面向对象设计和编程技术可称之为术，SQL技能也可称为术，UML各种绘图能力，ER绘图能力也称为术。

道和法，道为体，法为用，互为一体，是为核心，最为重要。单独讲道和法的理解比较干巴巴，也比较枯燥，我们先从文化来类比，可能更有体感。

西方文化是天主教、基督教的天下，摩西出埃及，建立《摩西十诫》，西方文化以宗教为本，摩西十诫是宗教的戒律，依此，摩西十诫作为西方文化的基础，一直影响着整个西方文化，注重契约精神，推崇契约行为，契约行为构成了西方的宗教行为、法律行为、民主行为。由此可见，西方文化的道是宗教，是摩西十诫，法是契约精神，契约行为。

中华文化则不同，先秦诸子百家，春秋战国百家争鸣，比同时期的古希腊文明更为自由，更为开放，虽然大家方式不尽相同。中华文化秦汉之前，儒、墨、道主导了全部的文化，唐宋以后，随着佛教的兴盛，变成了儒、释、道共同主导。所以中华文化的道是儒、释、道，法则根植于”内用黄老、外示儒术“思想，是”修身齐家治国平天下“，是”君子之行，静以修身，俭以养德“，是王阳明的”知行合一“，是曾国藩的“屡败屡战，愈挫愈勇”。

架构的道核心在于如何认识业务，如何客观且动态发展的看待业务，本质上根植于我们如何认识客观世界，如何借助逻辑的力量，如何认识系统，如何系统思考。架构的法则是基于架构的道，如何构建一套体系化的架构方法论来使我们的架构师们，架之有道，构之有理，每一个架构设计，架构升级都有一套行之有效的方法论来支撑，其方法论背后都有一套严谨且经得起推敲的逻辑。架构当然不是”自古华山一条路“，依然可以百家争鸣，百花齐放，只要你的架构之道和架构之法一脉相承，言之有理，理之有据，自成方圆，必然自信坦荡，广结善缘。

狄更斯说：”这是一个最好的时代，这是一个最坏的时代 “，一方面随着技术的日新月异，我们获取信息的途径和便捷度越来便捷，能接触的信息越来越丰富，越来越多元，单另一方面信息的急剧膨胀和技术更新迭代的加速，各种名词、概念、框架、流派层出不穷，观点各异，视角愈发多元，我们快速从信息闭塞过度到信息膨胀焦虑，面对巨量多元的信息不知道怎么选择，怎么吸收，怎么融合。在信息膨胀焦虑和快节奏衍生出的对耐心容忍度极低的浮躁中，能做到不盲从的独立思考尤为不易，但是独立思考不是空中楼阁，不是完全依据直觉的主观思考与判断，而是根植于丰富的知识体系的培育以及基于哲学思辨精神上的逻辑思维的养成，然后通过体系化思考方法论的储备融合达成。