首页 > 代码库 > 聊聊架构(1)

聊聊架构(1)

生命周期

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

架构

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

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

概念

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

抽象

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

识别问题

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

什么是架构师

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

<script type="text/javascript"> $(function () { $(‘pre.prettyprint code‘).each(function () { var lines = $(this).text().split(‘\n‘).length; var $numbering = $(‘
    ‘).addClass(‘pre-numbering‘).hide(); $(this).addClass(‘has-numbering‘).parent().append($numbering); for (i = 1; i <= lines; i++) { $numbering.append($(‘
  • ‘).text(i)); }; $numbering.fadeIn(1700); }); }); </script>

    聊聊架构(1)