架构设计实践五部曲（一）：架构与架构图.docxVIP

架构设计实践五部曲（一）：架构与架构图 什么是架构？我们先看一下百科中是如何定义架构的。 在百度百科中的定义是：架构，又名软件架构，是有关软件全体结构与组件的笼统描述，用于指点大型软件系统各个方面的设计。 在维基百科中的定义是：软件体系结构是指软件系统的基本结构，创建此类结构的规章以及这些结构的文档。需要这些结构来推断软件系统。每个结构包括软件元素，它们之间的关系，元素和关系的属性，以及每个元素的引入和配置的基本原理。软件系统的体系结构是一种隐喻，类似于建筑物的体系结构。 从百科中我们提炼出一句话，“架构是一种全体与局部关系的笼统描述”。这句话还是稍显笼统，不太简约理解。换个角度，依据中文的字面理解，对“架构“两个字进行拆解，就会发觉很有意思含义。架构从字面意思上，是源于古代的建筑术语。把架构拆分成两个字“架”和“构”。“架”就是“加”和“木”的结合，把木头加起来、连接起来就是架。“构”就是结构的意思。所以，“架构”就是把“木“依据肯定的结构连接起来。 下图为古代的木质建筑的结构图： 对应到软件架构，这里面的“木”代表什么，软件架构中的“结构”是什么，这些软件系统的“木”又是如何连接的？ 关联到软件领域，木就是系统中的要素，我们将他们称之为架构要素。架构要素可以是子系统、模块、应用服务。 结构，是架构的产物。不同的软件系统会有不同的结构，这些结构是为处理不同场景而设计的。 连接，通过定义架构元素之间的接口和交互关系、集成机制，实现架构元素之间的连接。连接可以是分布式调用、进程间调用、组件之间的交互关系等。 总结一下架构的本质，即架构 = 要素 + 结构 + 连接，将系统要素依据特定结构进行连接交互。 架构域的分类 在软件设计中架构域是如何划分的，架构域包括：业务架构、数据架构、产品架构、应用架构、技术架构。首先需要生疏业务，构成业务架构，依据业务架构，做出相应的数据架构和应用架构，最终通过技术架构落地实施。业务架构是战略，应用架构是承上启下，一方面承接业务架构的落地，另一方面影响技术架构的选型。如何针对当前需求，选择合适的架构，如何面对将来，保证架构平滑过渡，这个是软件开发者，特殊是架构师，都需要深化思考的问题。 业务架构 在需求初期，业务的需求描述往往比较模糊，可能只是一句话。他们可能来自老板、运营或者用户。直接把这句话作为核心产品功能是不恰当的，合理的做法是先把这个产品全部的问题域列清楚。 问题域，是指本人的产品能够处理的全部问题的空间集合。从核心需求动身，将全部当前需要处理、将来可能要处理的问题放入产品框架的范围。能够挂念我们的产品拥有更高的可拓展性，在后续具备迭代和优化的空间。 在经过问题域的陈列后，我们应当能够得到一个模糊的产品方向和功能范围。把这些问题域的答案笼统总结成一个确定的产品需求。依据核心需求和问题域的答案，梳理出业务流程。 业务架构就是在业务需求初期，将模糊的需求描述转变成清楚的问题域，梳理出清楚的业务流程。为产品架构供应输入。 业务架构包括业务规划、业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成笼统对象。没有最优的架构，只要最合适的架构，一切系统设计准绳都要以处理业务问题为最终目标，脱离实际业务的技术情怀架构往往是空中楼阁。 业务架构必需与其面对的实际应用场景相婚配，由于每个产品或项目的业务场景均有所不同，所以每次做新的软件开发前，必需设计软件架构。试图不经分析直接套用从前的架构方案，十有八九会让当前的系统在某个点上报出大问题导致推翻重建，更不要说直接拿别人的现成架构方案了。例如，A 业务中有套 A 系统，恰巧 B 业务需要处理类似 A 业务的场景。此时很多情况，B 业务的人员会考虑把 A 系统直接拿过来，以为做一些简约的修改，就能在 B 业务中落地。结果在系统落地的过程中，很多功能模块不能直接使用，都要重新依据业务进行修改。最终的结果是，A 系统经过不断的重写修转变成了 B 系统。 上述的案例正是由于业务架构没有做到位，没有做好软件架构的分析和设计，所以我们很难看出两个系统有多少差别，也无法确定用一个业务系统去掩盖另一个业务系统的可行性有多大。相反，对 A 和 B 业务领域进行业务架构梳理，我们就能清楚发觉两者的全都与区分，就能有效的评估系统掩盖的可行性和合理性。 经过业务架构阶段之后，需要输出的产物包括：企业战略方向图、问题域列表、业务流程图。 数据架构 企业架构由业务架构驱动，从业务架构分析业务流程、定义数据架构，流程和数据结合定义产品架构。这两头，数据架构起着至关重要的作用。企业 IT 系统的价值并不在于选取的技术有多先进，使用的硬件有多强大。而是企业业务数据的处理和存储。一家公司最贵重的资产无疑就是–数据。毫无疑问，在当今大数据的时代背景下，缺少数据资产的