参考文献

  • 极客时间 架构实战案例解析

架构的本质

  • 通过合理的内部编排,保证系统高度有序,能够不断扩展,满足业务和技术的变化.
    • 首先,架构的出发点是业务和技术在不断复杂化,引起系统混乱,需要通过架构来保证有序.
    • 其次,架构实现从无序到有序,是通过合理的内部编排实现的,基本的手段,就是"分"与"合",先把系统打散,然后将它们重新组合,形成更合理的关系.
    • "分"就是把系统拆分为各个子系统,模块,组件.
    • "合"就是基于业务流程和技术手段,把各个组件有机整合在一起.

架构的分类

  • 业务架构(概念)/应用架构(逻辑)/技术架构(物理)

  • 业务架构就是讲清楚核心业务的处理过程,定义各个业务模块的相互关系,它从概念层面帮助我们理解系统面临哪些问题已经如何处理.

  • 应用架构就是讲清楚系统内部是怎么组织的,有哪些应用,相互间是怎么调用的,它从逻辑层面帮助我们理解系统内部是如何分工与协作的.

  • 技术架构就是讲清楚系统由哪些硬件,操作系统和中间件组成,它们是如何和我们开发的应用一起配合,应对各种异常情况,保持系统的稳定可用.所以技术架构从物理层面帮助我们理解系统是如何构造的,以及如何解决稳定性的问题.

    举个拍电影的例子，来帮助你更直观地理解这三种架构的关系：

    • 业务架构定义了这个电影的故事情节和场景安排；
    • 应用架构进一步定义有哪些角色，每个角色有哪些职责，并且在每个场景中，这些角色是如何互动的；
    • 技术架构最后确定这些角色由谁来表演，物理场景上是怎么布置的，以此保证整个拍摄能够顺利完成。

  • 系统是人的系统，架构首先是为人服务的。因此，业务概念清晰、应用分工合理、人好理解是第一位的。然后，我们再考虑技术选型的问题，保证系统非功能性目标的实现.做架构设计时，一般是先考虑业务架构，再应用架构，最后是技术架构.

软件设计过程

  • 软件设计过程可以拆分成需求分析、概要设计和详细设计三个阶段.

  • 在需求分析阶段,主要是通过用例图来描述系统的功能与使用场景;对于关键的业务流程,可以通过活动图描述;如果在需求阶段就提出要和现有的某些子系统整合,那么可以通过时序图描述新系统和原来的子系统的调用关系;可以通过简化的类图进行领域模型抽象,并描述核心领域对象之间的关系;如果某些对象内部会有复杂的状态变化,比如用户、订单这些,可以用状态图进行描述.

  • 在概要设计阶段,通过部署图描述系统最终的物理蓝图;通过组件图以及组件时序图设计软件主要模块及其关系;还可以通过组件活动图描述组件间的流程逻辑.

  • 在详细设计阶段,主要输出的就是类图和类的时序图,指导最终的代码开发,如果某个类方法内部有比较复杂的逻辑,那么可以将这个方法的逻辑用活动图进行描述.