架构03 - 理解构架的视角

本文主要是介绍架构03 - 理解构架的视角，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

学习架构时，首要任务是弄清楚不同视角对于架构的理解，因为每个人对于架构的理解可能存在差异。不同职位对于架构的关注点也不同。开发人员更多关注开发架构，售前人员更多关注业务架构，运维人员更多关注运维架构，技术支持和部署人员更多关注网络和物理架构。

这样说清楚了一个观点：架构并不仅限于一种视角或者角色，而是综合了多个视角和角色的考虑。每个视角都可以提供不同的信息和关注点，从而帮助我们全面地理解和设计架构。

在学习架构时，应该尝试从不同的视角思考问题，了解各种架构所关注的要素和考虑因素。这样可以帮助我们形成一个更全面、综合的架构知识体系，并且更好地理解不同职位的需求和沟通。

1.架构的视角

在笔者的知识体系中，实际上将架构分为业务架构、应用架构、云基础架构这几大类，业务架构主要着眼于控制业务的复杂性，基础架构着眼于解决分布式系统中存在的一系列问题。无论何种架构，都希望能实现系统的可变的同时保障业务的高可用。

关注公众号：领取架构师面试资料

注意：

在实际情况中，架构的视角和分类并没有明确的边界，而是存在一定的交叉和综合。不同的架构视角之间常常相互关联和影响。

同时，软件架构与所在的部门组织架构之间也存在着直接的关系。组织架构决定了不同职能团队之间的协作方式和沟通渠道。这种组织架构也会反过来影响到软件架构的设计和演进。例如，若开发团队分为前后端开发，他们的组织结构可能会影响到系统的分层架构设计；若运维团队与开发团队合作紧密，运维需求可能会影响到系统的可部署性和可维护性等方面。

因此，我们需要意识到软件架构和组织架构之间的相互关系，充分理解不同视角的人员所关注的重点，并通过良好的沟通协作，以满足组织的需求和目标。这种综合性的考虑可以帮助我们更有效地设计和演化软件架构，使其符合组织的要求并支持业务的成功。

2.业务架构

核心是解决业务带来的系统复杂性，了解客户/业务方的痛点，项目定义，现有环境；梳理高阶需求和非功能性需求，进行问题域划分与领域建模等工作；沟通，方案建议，多次迭代，交付总体架构。

京东业务架构（网上分享图）：

3.应用/技术架构

根据具体的业务需求，我们需要设计应用的层次结构，并制定相应的应用规范、接口定义以及数据交互协议等。在此过程中，我们需要尽量控制应用的复杂度，确保它在可接受的水平上运行。这样一方面可以快速支撑业务发展，另一方面也确保了系统的可用性和可维护性，并满足了应用所需的非功能属性要求，如性能、安全性和稳定性等。

在技术架构的设计中，重点考虑系统的非功能性特征。我们需要对系统进行综合的考虑，确保其具有高可用性、高性能、可扩展性、安全性、可伸缩性和简洁性等特点。例如，通过设计容错机制和冗余部署来提高系统的可用性和容错性；通过采用性能优化策略、合理的资源管理和负载均衡技术来实现高性能；通过良好的安全设计和防护措施来保障系统的安全性；通过模块化和解耦等技术手段来实现系统的可扩展性和简洁性。

总之，技术架构的设计旨在在满足业务需求的同时，考虑系统的非功能性特征，确保系统能够高效、稳定地运行，并具备满足未来发展需求的灵活性和可维护性。

4.功能视角

5.技术视角

技术框架是一个可重用的设计，用于构建整个或部分技术系统。它由一组抽象构件和构件实例之间的交互方法组成。另外，技术框架也可以被技术开发者进行定制，作为应用的基本结构。

从技术角度描述，技术框架通常采用分层模型，包括持久层、数据层、逻辑层、应用层和表现层等。每个层次都使用不同的技术框架来支持开发工作。举例来说，持久层可能会使用Hibernate来管理数据库访问，数据层可能会使用Spring JDBC提供数据操作支持，逻辑层可能会采用Spring框架来实现依赖注入和控制反转（IOC），应用层可能会使用成熟的类库和中间件来支持业务逻辑，而表现层可能会采用MVC（模型-视图-控制器）架构来实现用户界面和交互。此外，还可以使用WebService等技术来实现系统间的数据交互和集成。

通过使用这些技术框架，我们能够将整个系统的主要实现概括起来，提供了一种结构化和标准化的方式来处理各个层次的功能和交互。这样的设计不仅可以提高开发效率，还能够增加系统的可维护性和扩展性，并且能够充分利用现有的技术和成熟的解决方案。

6.技术视角-基础架构

7.技术视角-运维架构

负责运维系统的规划、选型、部署上线，建立规范化的运维体系。

8.DDD到各种架构

领域驱动设计的战略核心在于将问题领域与应用架构分开，将业务语义明确化，将原本难以理解的业务算法逻辑通过领域对象和统一语言转化为清晰表达的领域概念。

换句话说，领域驱动设计注重将业务问题与技术实现相分离，使得业务领域的概念和过程能够更加清晰地表达出来。通过使用领域对象，即具有业务特性和行为的对象，可以将问题领域中的概念和逻辑进行抽象和显性化。同时，建立统一语言，即在组织 ** 享的业务术语和概念，有助于业务团队和开发团队之间的有效沟通和理解。

通过采用领域驱动设计的方法，我们能够更好地关注业务的本质，专注于解决业务问题。将复杂的业务逻辑和概念转化为形式化的领域对象和统一语言可使整个系统的设计更加清晰、可维护性更强，并且使业务需求的变更更容易实现。这种方法强调了业务领域的重要性，在设计和开发过程中以业务为中心，从而提高系统的灵活性和可扩展性。

统一语言，软件的开发人员/使用人员都使用同一套语言，即对某个概念，名词的认知是统一的，建立清晰的业务模型，形成统一的业务语义。将模型作为语言的支柱。确保团队在内部的所有交流中，代码中，画图，写东西，特别是讲话的时候都要使用这种语言。例如账号，转账，透支策略，这些都是非常重要的领域概念，如果这些命名都和我们日常讨论以及 PRD 中的描述保持一致，将会极大提升代码的可读性，减少认知成本。。比如不再会有人在会议中对“工单”、“审核单”、“表单”而反复确认含义了，DDD 的模型建立不会被 DB 所绑架。

面向领域，业务语义显性化，以领域去思考问题，而不是模块。将隐式的业务逻辑从一推 if-else 里面抽取出来，用通用语言去命名、去写代码、去扩展，让其变成显示概念；很多重要的业务概念，按照事务脚本的写法，其含义完全淹没在代码逻辑中没有突显出来。

职责划分，根据实际业务合理划分模型，模型之间依赖结构和边界更加清晰，避免了混乱的依赖关系，进而增加可读性、可维护性；单一职责，模型只关注自身的本职工作，避免“越权”而导致混乱的调用关系。通过建模，更好的表达现实世界中的复杂业务，随着时间的发展，不断增加系统对实际业务的沉淀，也将更好的通过清晰的代码描述业务逻辑，模型的内聚增加了系统的高度模块化，提升代码的可重用性，对比传统三层模式中，很有可能大量重复的功能散落在各个 Service 内部。