java技术架构图

架构图有哪几种

业务架构：需求初期业务的结果和过程描述一般比较模糊，可能来自于某个老板、运营或用户的反馈。客户说海尔洗衣机洗土豆会堵，海尔立马设计专门的土豆洗衣机业务方向往往是定方向和结果的叫战略，主要包括业务规划、业务模块和流程以及问题域的列表等。
应用架构：服务复用、跨组协同，简单、灵活、整合是应用架构必须考虑的点，就像你要上线一个聊天功能，那么聊天内容的输入法、文字识别、舆情监控以及视频服务、支付服务等，它们都是在应用架构分层下沉淀到平台的产物，在供各个方使用。
产品架构：业务提需求，产品定方案，相对于业务的粗放流程，产品架构会更加细腻以及考虑各个模块的分层和边界。
数据架构：数据的获取、数据的存放和数据的使用是数据架构要解决的三个问题，数据库存放、大数据汇总、数据分析等。
技术架构：是离程序员最近的架构设计，它不仅是系统搭建的架构图设计，还包括了结构、功能、流程、逻辑等内容。它的具体描述就是整个系统如何落地的具体实现方案。
Zachman框架
Zachman框架（Zachman framework）是一种逻辑结构，它可以对企业信息按照不同分类和不同角度进行表示。

Zachman框架，从横向六个角度看待企业，这个六个观点可以分为；什么内容、如何工作、什么地点、谁负责、为什么这么做（称为W5H）。

框架的列由一组工件组成，分为规划者、拥有者、设计者（架构师）、建造者、分包者、产品，或者有时表示为视点：范围上下文，业务概念，系统逻辑，技术，物理，组件组装和操作类。整体如图

表格横向六项代表了用于描述信息系统的某一个方面，对于任何一个事物只要在这几个基本方面对其进行清洗的解释就足够可以描述清楚。

数据（What，即什么内容）：什么是业务数据，信息或对象？
功能（How，即如何工作）：业务如何运作，即什么是业务流程？
网络（Where，即何处）：企业运营、部署在哪里？
人（Who，即何人负责）：什么人？什么是业务部门及其等级制度？
时间（When，即什么时间）：业务计划和工作流程是什么？什么时候执行？
原因（Why，即为什么做）：为什么选择的解决方案？这是怎么产生的？
表格纵向六项代表了在信息系统构造过程中所涉及到的人在描述信息系统时所采用的视角，包括：

范围/规划者（Planner）：此视图描述了业务目的和策略，充当其他视图将被派生和管理的上下文。
业务模型/拥有者（Owner）：这是对信息系统必须在其中运作的组织的描述。
系统模型/设计师（Designer）：该视图概述了系统如何满足组织的信息需求。
技术模型/建造者（Builder）：这是系统如何实施的表示，它使特定的解决方案和技术显而易见。
详细表述/分包者（Sub-Contractor）：这些表示说明了某些系统元素的特定于实现的细节：在生产开始之前需要进一步说明的部分。
功能系统/产品（Functioning Enterprise）：在1987年的论文（《A framework for information systems architecture》）中并没有这一行的内容，实际上此行的内容也并不在架构描述的范畴的之内，不过为了使得架构Zachman框架对于架构的表述更加完备，这一行最终还是被加了进去。
根据 TOGAF 的定义，企业是具有一系列共同目标组织的集合，而架构则是为了有效地实现这一系列目标。

在实现的过程中定义了企业的结构和运作模式的概念蓝图（SearchCIO），以及构成企业的所有关键元素和其关系的综合描述（Zachman）。通过创建、沟通和优化用以描述企业未来状态和发展的关键原则和模型以将业务愿景和战略转化成有效的企业变更的过程（Gartner）。

可以这一部分内容会比较绕，但可以作为架构设计的知识扩展进行学习理解以及运用。

DEMO

架构选型图

通常在新项目开发初期，都要做一些技术选型工作。在负载、网关、架构、治理、框架、服务、数据以及环境和支撑服务上，要选择适合当前开发的技术。

微服务架构

技术选型完毕后，接下来就是对于这些技术的运用。这个过程有点像搭积木一样，把每一个区域用适合此位置的积木填充进去。如果是团队初建或者是技术升级，那么这个过程还是比较复杂的，需要大量的验证。不过其实互联网的技术分层和使用已经相对稳定，搭建一个这样的微服务并不会耗费太长的时间。

技术架构图

技术架构图主要是对于研发层面做技术实现指导的，它可以把系统分层和实现结构划分清楚。另外一般也会把案例工程的结构拿出来一起讲解，这样可以让团队伙伴快速的进入开发。
————————————————————————————————————————————————————————————————————————————————————————

1. java 类加载器架构