一、先说几个现象：
1.1
我曾经的团队中的几位优秀的架构师，写框架代码写的很不错的那种。他们为什么能写出好代码？为什么能做出复杂系统的设计？ 他们自己好像也不能说出个所以然来。 我把这称之为意识流。（也就是大概是凭经验，靠感觉）并且，这种凭经验的说法也被不少DDD的专家大佬用来回答如何掌握领域建模能力上。
1.2
或者你也有一种感觉，你知道一些好的设计原则和模式，但是你不会用。 另外一种感觉就是UML的图你都会画，但是如果让你从0开始设计一套系统，你还是不知道如何开始。
1.3
只能凭经验这种说法，对于我一个管理者来说。它意味着不可快速培养，无法规模化；只能任由其自由生长，通过一个又一个项目来加强和验证一个人是否拥有良好的设计能力，是否有架构师的潜质 。 我始终无法接受这个结果。 虽然之前我也是一个经验和感觉型选手。
二、转机
2.1
转机的上半部分来自于我看了一书关于架构的神书《系统加构——复杂系统的产品设计与开发》 豆瓣评分达 9分。通常在8分以上就是值得一读的书了，9分的书读懂一本对某件事情的看法可能就会发生一些根本性的改观。这本书确实很难懂，至少我强行安利给了我身边的很多人，并且还组织过一段时间的读书分享小组。 这本书的作者对于架构的本质 ，以及如何来做架构是非常深的。虽然这本书的难懂确实让很多人放弃了，但我始终认为坚持看完3遍以上你对架构这件事情会产生很大的改观。
2.2
上面那本书虽然把架构的本质讲清楚了，但是并没有降低多少做架构的复杂度。直到我通过这种书里面用的概念建模语言OPM 找到了另一本书《基于模型的系统工程——综合运用OPM与SysML》 ，怎么说呢，我当时也是震惊的。因为这里面是这么说的：
功能是整个模型由此逐渐演变的种子。这条原理可能违反直觉。因为许多工程师倾向于从结构——对象、系统包括的实体，而不是功能开始建模。
也就是说它是从找到关键过程开始的，这有一种好像回到面向过程的方法里面去了。要知道在《面向对象分析与设计》里面，格雷迪大佬明确地表示这种结构化的设计过程是不可取的。
2.3
以公交车载客为例，如果是用面向对象的方式描述，就会把整个系统分为公交车，司机，乘客，车站等，然后分析它们在整个系统运作中的互动关系，关注的焦点是对象；而如果是面向过程，则会把整个从过程拆解为“开始跑路线-载客-启动-到站”，关注的焦点是过程。
面向对象的建模（当然，这是静态结构的建模，如果要对动态行为进行建模，我们还需要一个时序图来表示）
我们可以用乘客和司机为主体找到这样几个关键过程。（有人可能会发现这跟UML里面的用例图是很像的）
是的在OPM 里面会把角色也当成一个对象，它的类型是主体对象。主体对象作为一个人类对象操纵一个过程；但是如果接下来的操作可能会让你出乎意料了。
当然我们通过一个“过程”，它可以作为一个抓手或者推导，帮我们很自然地找到相关的对象。比如：
以乘客的上车和下车过程作为推导，你会找到什么？
三、OO VS OP
OO我们说的是面向过程，但是这里的OP 不是面向过程。而是对象过程 。OPM它的全称叫做Object Process Methodology 对象过程方法。是由以色列理工学院的Dov Dori教授研发出来的，它的目的是将面向对象的图表和面向过程的图表综合到一套方法中，更方便对系统架构进行描述。所以你看到上面将对象与过程放到了一张图里面。
它没有改变OO里面关于抽象、封装、模块化与层次的本质 。而区别于OO里面仅通过在总是域中找名称的形式来进行类的抽象，坦白讲这有点像老师跟你说你自己想一下。虽然这个道理很深奥，但是可能很难参透。
而OPM给我们带来的是找到关键过程，然后通过关键过程的链接（主体对象、工具对象、输入对象、受影响的对象）等，为我们搭建了一个桥梁，能够帮助我们降低抽象的门槛。并同时能够让我们利用OO的思想中的那些本质元素：抽象、封装、模块化与层次。 （OPM对于层次的建模不需要像UML那样分为多张图）
四、这是广告
我在我们一期功能架构训练营中将架构过程与OPM相结合，打造了一套科技学落地架构设计过程与方法。同学学完之后是这么说的：
学习这个打开了我的新世界 ，原来这个还有方法论。我也有下载你说的那个系统架构：复杂系统的产品设计与开发，用琐碎的时间看了前面2张，后面就扔掉了。从投资与回报来说，你的课程确实性价比特别高。
在前几天我还没有意识到虽然这个过程是已经存在的，但是它之前是被应用在更广泛的系统设计上（比如硬件或者其它系统），但是在软件设计领域，可能还没有。（如果有的话麻烦告诉我- -、） 想想这个过程可能拯救国内600万被OO搞的头大的程序员于水火之中，这件事情就值得我好好地去推广。
京公网安备 11010802035086号