很多人担心编程是个青春饭，觉得30岁以后代码就写不动了，35岁以后就应该转型做管理。Gevin觉得这个大可不必担心，做不做管理之类的随缘，编程也不是青春饭，而是一种可以做到“live and learn”的技能。不过，代码写到一定程度之后，技术还要继续提高或者升维的，架构师就是一个自我提升的不错方向。架构设计虽然与做开发紧密相连，但试图通过量变引发质变貌似还是困难的。做架构师也是要掌握方法论的。今天，Gevin分享一下自己在架构设计上的一些思考。
1. 为什么要做软件架构设计？
做软件架构是为两件事服务的：业务架构和业务量级。
业务架构和业务量级都是从每个具体项目的实际应用场景中提炼出来的。
业务架构是对业务需求的提炼和抽象，开发软件必须要满足业务需求，否则就是空中楼阁。软件系统业务上的复杂度问题，可以从业务架构的角度切分工作交界面来解决。设计软件架构，首先是要保证能和业务架构对的上，这也是从业务逻辑转向代码逻辑的过程，所以软件架构的设计为开发指明了方向。另外架构设计也为接下来的开发工作分工奠定了基础。
业务量级表现在存储能力、吞吐能力和容错能力等，主要是软件运维期业务的复杂度。做软件架构设计，是要保证软件有能力托起它在业务量级上的要求的，如果软件到运行使用期废了，前面所有的工作都付诸东流了。不同的业务量级，对应的软件的架构复杂度是不同的，所以对于不同的项目，业务量级不同，架构设计也不同。
做业务架构必须与其面向的实际应用场景相匹配，由于每个产品或项目的业务场景均有所不同，所以每次做新的软件开发前，必须先设计软件架构，试图不经分析直接套用先前的架构方案，十有八九会让当前的系统在某个点上报出大问题导致推翻重来，更不要说直接拿别人的现成架构方案了。
所以每个软件在开发前，都要结合自己的应用场景设计适合自身的软件架构，现成的架构方案只能借鉴，不能直接套用。
另外，由于业务架构和业务量级也会不断调整或长大，软件架构也不是一劳永逸的，会随业务不断调整。
2. 为什么做业务架构？
我工作中很多情况下，当大家提到架构的时候，往往会直接往软件架构上去靠拢，经常会不自觉的直接让做研发的同事或所谓的软件架构师去做架构设计了，这都为我们的软件项目的顺利开展埋下了隐患。所以，关于为什么做业务架构，我可以结合实际工作中见过的坑来解释。
业务架构是左右一个软件项目能否顺利开展的总纲，软件架构是业务架构在技术层面的映射，合理的开发分工也应该基于业务架构去做。如果没有业务架构，软件开发会很盲目。 业务架构是需求和开发的汇聚点，需求是否做到位，功能开发是否到达预期目标，都以此为依托。我们在工作中遇到的一些问题，如研发的人说需求做的不到位，而做需求的人会质疑需求做到怎样对开发而言才算到位，为什么开发出的东西和用户要的不一致，这些从根上说，没有把业务架构梳理清楚是源头，没有在此达成共识，想在由此往上展开的细节上达成共识成本更大。
所以，我们在软件项目上，应该回归本位，基于业务架构去做软件开发，在全面动工之前，先在业务架构上达成共识。虽然有时不梳理业务架构，软件也能做出来，但这要么是业务逻辑简单，要么是我们有充裕的时间。如果想高效的、目标导向的做软件，业务架构要重视。
业务架构是树型结构，是可以不断细化，一直分解到最末端的叶子节点的。对于软件开发而言，以业务架构为依托，架构师和开发者能比较清晰的看到系统的业务全貌，架构师能更方便的去分析系统复杂度，分解业务逻辑，做好开发的分工。
站在软件项目的角度看，项目前期做好业务架构设计，对整个项目的开发具有重要意义。例如对于比较类似的业务系统，可能业务架构在比较粗的颗粒度上是一样的，而在细化过程会不一样。做项目时，当手头有一个现成的系统，现在要做一个需求类似的项目时，大家可能会首选尝试用现成的系统去覆盖新项目，以求利益最大化，该想法能否实现，就可以通过业务架构来衡量，如果没有业务架构，接下来的工作会非常盲目。我在工作中就遇到过，做市场的同事发现两个业务领域存在一致的业务需求，打算用我们在A领域完成的AS系统直接去应对B领域的需求，以为只要在细节之处做简单修改即可，结果在系统落地过程中，很多功能模块都重写了。最终的结果，不是拿AS系统去应对AB两个领域，也没做到把AS系统改造为适用于两个领域的ABS系统，而是以不断改造AS系统的方式，为B领域做出了一个独立的BS系统。
这是开发和项目经验不足导致的，再深挖一下问题点，可发现正是由于业务架构没做到位、没有以业务架构指导软件架构设计导致的。由于两个业务系统都没有做好业务架构的分析和设计，所以我们很难看出两个系统有多少差别，也无法确定用一个业务系统去覆盖另一个领域的业务的想法有多大的可行性或改动量。相反，如果两个业务领域都事先梳理的业务架构，我们可以很清楚的看到，从哪个节点起两边的业务逻辑开始出现分叉，从而通过进一步的评估可以得知改动的复杂度，如，是不是只要从分叉节点开始重新功能实现就好了，还是说该变动还会影响到分叉点以上的一些节点，如果它的上级节点改动了，它的兄弟节点要不要调整等等。
所以对于这个案例，如果事先做好了业务架构，是可以比较准确的对软件系统的开发做出预判的，对接下来的工作安排具有指导意义。（从开始就奔着做一个独立的系统，与不断遇到问题不断改造已有系统直至系统被完全更替掉，无论在项目管理还是在工作体验上，都是完全不同的。）
3. What’s More？
顺着上面的思路，关于业务架构和软件架构，还能再扩展一下。
由于业务架构是软件开发的总纲，软件架构是在计算机层面对业务架构的映射，所以业务架构变化，必然会导致软件架构的调整；而这与软件架构或框架的存在并不矛盾。我们之所以会有一些通用的软件架构模式，或者软件框架，是由于这些都是常见的、通用的业务逻辑的抽象，例如做网站最经典的MVC架构模式，就是在比较粗的颗粒度上，业务架构向软件架构转换时的一种通用且适用的映射方式；而各类web框架，那是在软件层面实现业务功能时那些基础功能点的抽象化和标准化。这就像乐高的各种基础积木，而各种乐高模型的搭建还是要靠图纸，其中，类比中的对应关系见下表：
| 乐高 | 软件 |
|---|---|
| 模型对应的实物 | 软件预期 |
| 对实物的分析和分解 | 业务架构 |
| 图纸 | 软件架构 |
| 模型 | 软件成果 |
依托于两个架构的设计，项目团队的人员分工也是可以得到落实的。工作分解的主要过程，其实就是不断梳理业务逻辑，提炼核心业务生命周期，剥离非核心业务生命周期的过程，凡是能够剥离出来的，都是与核心业务逻辑松耦合的非核心业务，可以分出去独立完成，而一个业务的生命周期内部，往往是高内聚的，开发成员之间配合紧密，管理和协作如果不到位，人员增减都会降低效率。
工作分工的事情姑且一提，挖个坑以后又机会继续填~ :P
注：转载本文，请与Gevin联系
欢迎关注我的微信公众账号
