提起企业架构很多朋友都不明白其与数字化转型之间的关系，其实可以这样了解：将数字化转型的本质当成技术对业务的重塑，那么为了达到重塑的目标，就需要企业具备数字化的核心力量。而企业架构就相当于技术实现与业务模式之间的桥梁，可以帮助提高数字化转型的核心力量，因此企业架构在数字化转型中承担着非常重要的助力作用。下面我们来聊聊架构。
1、什么是架构和架构本质
架构一个系统在其所处环境中所具备的各种基本概念和属性，具体体现为其所包含的各个元素、他们之间的关系以及架构的设计和演进原则之中。
架构的本质就是对系统进行有序化地重构以致符合当前业务的发展，并可以快速扩展。
2、企业架构和系统架构
架构从应用上可以分为企业架构和系统架构。
企业架构（Enterprise Architecture）是记录企业内所有信息系统、它们的相互关系以及它们如何完成企业使命的蓝图，是企业关注点。
系统构架是对已确定的需求的技术实现构架、作好规划，运用成套、完整的工具，在规划的步骤下去完成任务，是系统关注点。
3、架构的作用
复杂的软件项目通常有两个明显的特征：需求不确定和技术复杂。需求不确定来自于客户，而技术的复杂性主要体现在需求让技术变复杂、技术本身也是复杂的、要让软件稳定运行是复杂的。这些技术的复杂性，会导致软件开发变得复杂，开发成本很高，架构设计恰恰可以很好解决技术复杂的问题。首先，架构可以降低满足需求和需求变化的开发成本。其次，架构可以帮助组织人员一起高效协作。再次，架构可以帮助组织好各种技术。最后，架构可以保障服务稳定运行。
4、什么是视角和视图
视角（Viewpoint）：一个针对某视图所采用的观察角度的定义，是构建和使用某视图的规约的描述（通常采用一个适当的模式或模版的形式）。通俗的说，视图描述了所看到的内容；而视角则描述了站在何处进行观察——一个能够决定你所能看到的事物的制高点或角度。
视图（View）：针对一系列相互关联的关注点的表达。一个视图描述了采用某个视角后所看到的事物。架构视图可以通过模型来进行表述，从而为不同的干系人根据各自针对架构的关注点而分别提供描述。一个视图从本质上讲不一定以可视化或图形化的方式进行展示。
5、常用的架构视图
业务架构：核心是解决业务带来的系统复杂性，了解客户/业务方的痛点，项目定义，现有环境；梳理高阶需求和非功能性需求，进行问题域划分与领域建模等工作；沟通，方案建议，多次迭代，交付总体架构。
应用架构：描述了IT系统功能和技术实现的内容，应用架构分为企业级应用架构和系统级应用架构。
逻辑架构：逻辑架构关注的是功能，包含用户直接可见的功能，还有系统中隐含的功能。
数据架构：更关注的是数据持久化和存储层面的问题，也可能会包括数据的分布、复制、同步等问题。
物理架构：关注软件元件如何部署到硬件上，专注于系统、网络、服务器等基础设施。
开发架构：开发架构则更关注程序包，不仅仅是我们自己写的程序，还包括应用程序依赖的SDK、第三方类库、中间价等。
运行架构：关注的是应用程序运行中可能出现的一些问题。例如并发带来的问题，比较常见的“线程同步”问题、死锁问题、对象创建和销毁（生命周期管理）问题等等。
6、架构与中台、微服务和DDD关系
中台就是通过可复用的应用架构设计来支撑易变复杂的数字化业务。中台解决的是企业层面的能力重用问题，本质上中台是企业架构中的应用架构或业务架构。
微服务就是将一个单体架构的应用按业务划分为一个个的独立运行的程序即服务，它们之间通过 HTTP 协议进行通信（也可以采用消息队列来通信，如 RoocketMQ，Kafaka 等），可以采用不同的编程语言，使用不同的存储技术，自动化部署（如 Jenkins）减少人为控制，降低出错概率。微服务解决了系统的拆分和重组问题，为系统水平拆分和垂直拆分提供理论方法，属于系统架构中应用架构的范畴。
DDD（领域驱动设计），它是对面向对象的的分析和设计的一个补充，对技术框架进行了分层规划，同时对每个类进行了策略和类型划分。领域模型是领域驱动的核心，采用DDD的设计思想，业务逻辑不再集中在几个大型的类上，而是在大量相对小的领域对象上，这些类具有自己的状态和行为，每个类都是完成的独立的，并与现实领域的业务对象形成一种映射。基于DDD的架构设计，保证了系统的可维护性，扩展性和敏捷性，在处理复杂业务逻辑方面有着明显的优势。DDD解决了微服务内模据拆分和设计问题，属于系统详细设计方法的范畴。
7、小结
本篇文章主要分享了架构领域的基本概念，如想系统了解架构理论建议研究TOGAF模型，架构理论指导我们如何解决问题的、用到哪些方法，不断地积累这些方法，形成通用的架构设计方案，在实际的工作中，遇到类似的场景时，可以选择合适的方案来解决实际问题。同时也简单介绍了中台、微服务和DDD，与架构的关系。
