---

1 导学

本章博客我们来学习java项目架构设计与落地应用的导学。为什么这偏文章对我很重要？首先呢我们来看一些常见的困惑。我们来学习路在何方，大家统一一个认识，选对方向，朝着同一个目标前进，不走错路，不走弯路，这就是最快速的路。先从架构师的角度来看待架构并深入理解。依次去学习和理解架构分类、架构设计、功能设计、架构师等等核心的概念，并深入去分析架构师的核心技能要求，也就是我们要学习的方向。

我们学习的目标是要快速成长为合格的架构师，那需要什么样的核心技能呢？

简单的说啊就是成长为合格的架构师需要学什么，咱们就学什么。需要掌握到什么样的程度，我们就学到什么样的深度。这样的话咱们就不会走错路，不会走弯路了。

另外呢在本章后半部分还会去学习大道至简，基本的设计思想都是架构设计非常重要的一些思想。
这里呢咱们只讲几个最核心的。

1 面向对象设计的核心思想，封装

咱们开始学习面向对象就讲封装继承多态，封装是面向对象设计最核心的思想之一。

2 一个面向对象设计的重要技巧隔离
我们为什么要去封装对象？
如何去封装组件、划分模块、划分子系统等等的。这些都体现了隔离的思想。
封装加隔离可以说是面向对象设计最重要的设计基础。

3 学习架构设计和开发的重要步骤，就是从大到小，由粗到精，逐步细化
这个也是咱们去学习一门新技术，掌握一门新技能的基本的学习方法和学习步骤。

4 架构设计和开发的核心方法，迭代
我们做任何事情都不是一蹴而就的，需要不断迭代，螺旋式前进，最终去完成咱们的目标。
这些思想对大家来说都是耳熟能详的，在这里呢会结合老师多年的经验和理解，再深入的去讲一下，希望大家能够好好去领悟。

1.1 技术提升依然突破不了职业的瓶颈

这是很多人的困惑。感觉自己各种技术学了一大堆，项目也做了不少，可就是突破不了职业的瓶颈。这个时候你要考虑是不是自己学习的方向不对。

如果你只是围绕开发去学一大堆的开发技术，那么我可以告诉你，你就会面临这样的问题，觉得技术上学了一大堆，可自己呢依然在原地打转。这个时候你需要向上走从开发往架构上走。

也就是你应该学的是架构设计，而不是单纯的围绕开发去学各种开发技术。本课程就是你学习架构设计，快速成长为架构师的最佳选择。

1.2 技术提升可薪资依然涨不上去

其实原因很简单，虽然你学了很多的开发技术，但是你还是只能承担一些开发的任务，不能勇挑重担去承担系统的架构设计、难点攻关、基础框架设计与落地。
但更有挑战性的工作不能够更进一步，自然也就很难升职加薪了。

1.3 学了架构课程依然觉得自己成长很慢

这也是很多人的困惑。感觉自己看了很多架构方面的书，也听过很多架构方面的课，但是在实际工作当中做的架构却无法落地，会感觉自己的成长特别的慢。
其实呢这是因为你缺少真正的架构设计方面的实战训练，浮于知识的表面。

2 架构的基本认识

2.1 什么是架构

说到架构，我们就会想到软件开发的另一个词：框架。

那么什么是架构，什么是框架，他们的区别又是什么呢？

其实，架构关注的是系统的结构，即系统的组成，需要明确系统有哪些子系统或模块组成。以及这些子系统是如何协作的、如何通信的等。如淘宝架构，微信架构。框架关注的点是一个可复用的基础功能的软件产品。如MVC框架、Spring框架等。

2.2 为什么要做架构设计

什么是架构
这里选取IEEE(电气和电子工程师协会)的定义
架构描述了一个系统的基本组织结构，包含了组成系统的组件组件之间的关系、组件与环境之间的关系，以及指导上述内容进行设计和演化的原则

系统:组织起来完成一系列功能的组件集

组件:组件是一个系统模块化的一部分，一系列功能集的封装体

从设计角度来看:本质是一样的组件<模块<子系统<系统

环境:环境或上下文，指的是会对这个系统的开发、运行等造成影响的环境和设置

3 深入理解和认识架构。

架构定义了系统结构，尤其是高层结构
架构呢就是结构，是谁的结构呢？就是软件系统的结构。
一般来说我们做架构的时候，不去关注这些具体的功能实现，而是把着眼点呢放在这个高层结构之上。

那可能有人就会在想呢，那啥是高层结构呢？
简单点说啊，就是比较粗略的、概要的轮廓性的这样的结构。那可能有人觉得说这个东西还是不太好想象。那我们打个比方，假如说我们现在这个软件系统就是一栋已经修建好的大楼。
那么这个高层结构呢，其实就是你修这个大楼的时候搭建的这些柱子横梁这样子的一个框框，把它类比到软件系统里面来，这就是软件系统的高层结构。

3.1 架构定义的行为。

这里所说的行为呢主要是指一些交互行为。
比如说组件之间的交互，组件和环境之间的交互等等。
那前面呢咱们也讲到了组件之间的交互也可能说是有调用关系，有依赖关系，有扩展等等的，这个呢就不多说了。

3.2 架构关注系统的主要元素

刚才提到我们做架构的时候，一般来说不去关注具体的功能，而是着眼于高层的结构。也就是说着眼点呢不会放的那么的细致。那么我们做架构的时候就会关注这个系统里面的一些主要元素。

那哪些算是系统里面的主要元素呢？
比如说你从用户角度来看，用户所关注的一些重点难点的功能，这肯定是主要元素，或者说在用户看来是有特色亮点的功能。
这个也算是主要元素。另外呢就是一些解决重要特性的元素。
比如说用户要求的影响到高性能、高可用或者安全性的这样子的一些元素。
通常也就是我们所说的质量属性。这些呢就是咱们做架构的时候应该要重点关注的主要元素。第四的一个架构要平衡系统利益相关者的需要。那这里首先呢咱们要知道啥叫系统利益相关者。
他指的呢就是对这个系统感兴趣，或者对这个系统有关系的人，团队或者组织。
那么这些呢都统统系统相关的这这里呢大家注意一点，系统利益相关者并不一定直接使用或者是操作这个系统的才叫利益相关者。他只要是对这个系统感兴趣，或者是对这个系统都可以称之为系统利益相关者。比如说客户方的老板，他可能不会直接去使用这个软件，但是他要付钱，他可能就会对这个系统提出一些要求。比如说他要求你的系统会怎么样，他要求你的这个可扩展性会怎么样。
所以说呢他也是一个系统利益相关者，而且呢他会提出他的要求，也就是有他的需要。当然就更不要说啊直接使用这个系统的这些人。比方说从客户方的角度来讲，参与业务使用的这些人当然肯定是利益相关者。从开发方来讲，所有参与这个系统的开发的这些人员通通都算是利益相关者。
从你前期的调研到底整个设计、开发、测试、运维以及整个项目管理的人员。那么所有的这些人围绕着这个系统通通都叫利益相关者。

那这样看起来的话，他会发现对于一个系统来说啊，利益相关者是非常非常的多。不同的利益相关者，他们的关注点通常是不一样的，甚至有些关注点是相互冲突的，甚至是矛盾的。比如说老板他要求说这个东西必须很省钱，然后使用的这边有些人可能说要求这个性能非常的好，但是呢系统管理部门又要求这个系统的安全性要非常非常的高。那大家一想就知道，安全性非常高就意味着你需要做的检测会非常的多，要求会非常的严格，这些对于系统的性能是有损耗的。所以说呢，不同的关注点很有可能是有矛盾的或者是冲突的。

3.3 平衡关注点

也就是要去平衡不同的这些系统利益相关者的需要。因为他们不同的需要就是不同的关注点。
架构呢是基于合理的证据来使得这个决策呀俱体化。

架构设计肯定不是拍脑门，不是架构师头脑一热说我们就要做成这样这样子的一个架构，而是基于一些合理的证据，当然这个证据可以是直接的，也可以是间接的证据，但是呢一定是合理的这样子的一些证据。

比如说你可以是同类产品的参考，别人已经做成功了，你看他们是什么样的一个架构形式，那我们是不是可以参照，因为人家已经做成功了嘛，这也算是合理的证据。
或者说是架构师架构团队以前设计的经验。或者说专门为了这个系统的架构去设计一些架构方面的demo来做的实际测试，来证明这样设计是可行的，从而使得这个决策是透明化的，具体化的。

3.4 架构会受到环境的影响

比如说架构会受到法律法规的一些要求。另外呢它还会受到一些行业标准的约束。
你做的行业不同，它可能行业会有一些呃行规，你做的这个架构也要受行业标准约束。
那么除了这些啊，咱们在实际的这个工作当中还经常碰到的一类就是咱们做的软件通常只是客户方复杂的软件需求里面的一部分，那么它可能已经有很多的软件系统在运行当中呢。
而我们现在要做的这个软件项目呢，需要去和已有的已经存在的这些软件项目相融合。
那么这个时候就有可能对咱们现有的软件系统架构形式、技术选型产生一定的影响。
另外呢，咱们做的这个系统还需要和已有的一些系统进行交互。
这些都是指咱们的架构会受到环境的影响。

3.5 架构会影响开发团队的结构

打个比方来说，那么现在啊咱们很流行微服的架构。假设说现在的这个系统的架构形式已经决定采用微服的架构。那么我们相应的开发团队就需要按照匹配微服务开发的这个方式来建设和组织。这就是一种典型的啊架构，会影响开发团队的结构

4 架构分类

众说纷纭的架构分类。事实上啊业内对于架构的分类也没有一个统一的标准。
我们也看到过听到过太多的关于架构分类的方式。
那总结起来了大概有这样一些，有按照实现层次来划分的，有按照关注方向去划分的，也有按照软工阶段来划分的，还有呢按照视图类型进行划分的，还有按照技术实现风格划分的等等很多种不同的架构分类的方式。虽然有这么多种分类方式，但是从本质上来讲，架构这件事儿并没有变化。
只是呢从不同的角度，不同的侧重点对这件事情呢进行了划分。因此啊有很多的划分实际上是会交叉重复的。接下来呢我们就一起来看一下，为了节约时间，我尽量啊少去解释这些架构的分类，大家有个印象就可以了。

相关文章
软件架构思想和系统架构图：https://blog.csdn.net/ZGL_cyy/article/details/126414922
互联网架构演进之路：https://blog.csdn.net/ZGL_cyy/article/details/126330968
中台架构介绍和应用价值：https://blog.csdn.net/ZGL_cyy/article/details/126317750
互联网架构演进方向：https://blog.csdn.net/ZGL_cyy/article/details/133040892