聊聊架构(1)

生命周期

接触React的同学肯定对生命周期印象深刻，这是相对于组件而言的生命周期。举一个生活栗子，我们在一次购物场景中，从用户进入到商店，进行浏览、询问、购买等活动，到离开商店，也可以看做是一次购买活动的生命周期，这个生命周期的主体是购买活动。一个生命周期里面的活动可以进行拆分，拆分的原则就是形成若干个新的生命周期，每个新的生命周期都有自己的主体，比如上面说到的购物活动，又可以拆分成物品的选购和物品的购买两个小的生命周期。物品的选购这个生命周期的主体为用户的物品意向，以用户进店开始，以意向确定或放弃为终，而物品的购买这个生命周期的主体仍然是用户的购买活动，但是主体的生命周期活动内容减少了，变成以物品确定为开始，以交易成功或失败告终。我们也把拆分之后主体不变的子生命周期，称为核心生命周期，主体改变的子生命周期，称之为非核心生命周期。寻找核心生命周期的过程，实际上也就是一个发现内聚的过程。对于非核心生命周期，本身内部也需要寻找出它自己的核心生命周期。
物品选购结果的确定是核心生命周期需要的，也就是说执行还是必须在购买之前，但选购生命周期的运营，则完全可以交给别人来执行。如今的网上购物、智能推荐等都是在这个地方发力。拆分的同时会带动产生很多新的有意思的生命周期，形成新的技术，比如商品的规范化、货物的配送等。
从生命周期内部来看，生命周期的每个阶段是随着时间的推进而发生变化的，也就是所谓的业务流程。
在对生命周期探讨的过程中我们发现，生命周期和周期的关系非常紧密，而时间不过是人们对事物变化的一个度量。

架构

举一个社会分工的例子，社会分工把原来每个人所必须做的非核心生命周期工作，切分成由不同角色的人分别来完成，这样就形成了人类社会的架构。当每个人的时间有限，擅长的技能不同，社会分工下的社会架构就自然而然形成。那么我们就发现架构包含以下几个要点：
1. 根据要解决的问题，对目标系统的边界进行界定。问题主体的确定一般就能确定边界，问题的确定可以明确核心生命周期。
2. 围绕目标系统核心生命周期进行切分，切分的原则是要让非核心生命周期独立出来，便于不同的角色并行开展工作。首先要在空间上拆分，使得空间上的管理可以并行，而时间执行上串行。因为只有空间上并行后，进一步可以通过预先执行好结果，达到时间上并行的效果，缩短整个生命周期。
3. 对这些拆分出来的部分，确定各自的生命周期及其主体，以及负责的角色。不同角色对所负责的生命周期负全责。
4. 在这些拆分出来的非核心生命周期和核心生命周期之间设定沟通，使得这些非核心生命周期能够围绕核心生命周期，通过树状结构组装起来成为一个整体，共同为核心生命周期做出贡献。为什么是树状结构呢？因为核心生命周期本身是按照时间线性推进的，拆分之后非核心生命周期会围绕核心生命周期形成树状的架构。

架构是对业务生命周期的拆分，自然业务的生命周期就是架构的生命周期。架构的生命周期可以被拆分成两个子生命周期：架构设计生命周期和架构实施周期。其中，架构设计生命周期是为架构实施生命周期服务的，因此架构实施是生命周期是架构的核心生命周期。

概念

概念是人相互沟通并认识这个世界的基础。每个概念实际解决的，是人遇到的某个特定的问题，人们把解决问题的解决方案，给定了一个名字，这个名字就是对应的某个特定的概念。根据架构的定义，要做好架构首先必须具备的能力就是要能够正确地认识概念，能够发现概念背后所代表的问题，认识目标领域的核心生命周期，这样才能为做好架构打好基础。事实上，这一能力要求在任何一个领域都是适用的，比如人们如果想要学习一项新的技术，如Hibernate、Spring等，先去探索这些概念产生时所要解决的问题，学习这些新的技术或者概念就会快速上手。

抽象

每个事物都有其独特的地方，我们称之为事物的个性。要定义一个事物，只能用这个事物独特的地方，也就是它的个性。而抽象恰恰关注在共性上，很多人喜欢采用抽象来定义一个概念，抽象实际上是把不同概念的相似部分结合到一起，形成一个新的概念。这里面有一个问题：首先相似的部分在不同的人看来，并一定那么相似，这回导致不同的人定义出来的概念不一样，其次，抽象之后形成的是一个新的概念，有自己的个性，和原来那个概念所代表的个性并不一样。

识别问题

我们先来看一个笑话：一位女士对老公说：把袋子里的土豆削一半下锅。结果所有土豆都下锅了，并且锅里煮的每一个土豆都被削了一半皮。沟通中大家基本都会面临一个很大的问题：缺乏主语。把原因归结为沟通问题也是可以的，但是这个问题更深层次的原因是目标主体的不明确。如果明白了问题的主体，这个主体自然会带来很多的边界约束，比如土豆是要吃的，是要给人吃的。挖掘出隐含信息，就自然而然能够问出来其他问题了。当我们处理问题的时候，如果发现自己正在致力于把自己的工作完成，就要马上警惕起来起来，因为这样下去会演变成没有主人翁精神的工作态度，在面对概念的时候，也会不求甚解。从上面的分析可以看出，找出问题的主体，是做架构的首要问题。再来举一个软件行业都比较熟悉的例子：用户向产品经理提出要求，想要一把锤子，这就是典型的把解决方案当做问题的。真正有问题的主体是谁，是用户、设计师还是施工队？如果产品经理当做是自己的问题，那么毫无疑问会给用户一把锤子了。产品经理需要识别，用户究竟是二传手，还是问题的真正主体。

什么是架构师

架构师会把需要增长的业务了解清楚，挖掘出核心生命周期，并确定核心生命周期的主体，并根据当前人员的状况，合理分配非核心生命周期的权责。这样不同的人就可以并行地互不影响地做不同的事情，最后根据核心生命周期，把他们的工作成果组合起来。
架构实际上是一种通用的行为，只是大部分人们自己没有意识到而已。比如很多人的办公桌看起来乱七八糟，但是他的工作非常有效率，因为他在长期实践之后，根据自己每天的工作，整理出自己工作的核心生命周期，与其相关的每样东西都摆放在合理的位置，其他的东西都放在非关键路径上。这个时候他已经在做架构思考了，因为他已经专注在自己工作的核心生命周期，把非核心的都尽量剔除掉。
介绍完基本概念，在下一篇中，我们开始具体聊软件中的架构聊聊架构(2)。