分层架构是罕用的架构设计办法，本文探讨了分层架构的概念、劣势、最佳实际，并给出了在架构设计中罕用的命名约定。原文: Layered Architecture in Software Architecture: Concept, Benefits, and Best Practices
分层架构是软件开发中宽泛应用的结构化设计办法，该办法将零碎划分为不同的层，每个层都有特定用处并与其余层交互。本文将探讨分层架构的概念、长处以及施行的最佳实际。
分层架构以四个关键问题为领导：用户 (who)、性能(what)、部署(where) 和施行(how)。
-
用户(Who) —— 开发满足用户需要的产品或零碎。
- 客户互动 —— 踊跃与应用产品的客户或顾客接触。设计人员和开发人员须要收集需要、召开会议并征求反馈意见，以确保最终产品合乎客户的冀望和指标。
- 确定用户角色 —— 用户角色是依据用户的职称、职责或特定规范调配给他们的预约义类别。
- 定义界面 —— 界面是用户与零碎或产品之间的交互点。界面设计要思考信息架构、视觉设计、交互模式和可用性准则等因素。原型设计、线框设计和用户测试通常用于欠缺和验证界面设计。
- 思考可用性 —— 易于应用。可用性测试包含工作、场景和实在用户，以评估产品的可用性。
-
性能(What) —— 定义零碎的性能、特点和高级模块。
- 零碎性能 —— 定义零碎能做什么以及如何与环境互动以实现目标，概述了零碎的具体操作、输出、输入和限度。
- 业务性能 —— 代表零碎的具体性能或特色，为用户提供价值。依据零碎的性质和复杂程度，能够是基本功能，也能够是高级操作。通常源于零碎性能，旨在满足特定的用户需要。业务性能通常作为零碎需要或规格的一部分记录在案，并作为开发和测试的根底。
- 高级模块 —— 封装相干性能或个性，代表了可独立开发、部署和治理的内聚性能单元。
-
部署(Where) —— 侧重于零碎的基础设施方面，波及利用网络工具和服务、设计网络基础设施、思考分布式网络架构、利用基础设施即代码实际以及优化网络性能。
- Azure 网络架构 —— Microsoft Azure 提供各种网络工具和服务，如 Azure 虚构网络、Azure 虚构广域网、Azure 专用链接和 Azure 防火墙，以反对工作负载和服务。
- 谷歌云网络设计 —— 谷歌云提供虚构专用云(VPC) 的应用、网络安全治理以及评估寰球或地区服务的利用需要。
- 分布式网络架构 —— 为要害工作利用提供牢靠的根底，易于扩大，并能适应一直变动的利用和服务流。
- 网络架构物理域 —— 网络架构正在一直倒退，以反对具备认知治理性能的高度自动化网络。这种转变波及动静适应性、云资源分配、联结数据管道和开放式 API，指标是优化性能、老本和业务敏捷性。
- 基础设施即代码 (IaC) —— 基础设施即代码(IaC) 是一种 DevOps 实际，通过描述性模型治理基础设施，涵盖网络、计算服务、数据库、存储和连贯拓扑。施行 IaC 有很多益处，如加强部署信念、治理多个环境以及更好的理解基础架构状态。
-
施行(How) —— 施行细节，包含架构模式和层与层之间的通信机制。
-
架构信息传递模式 —— 用于促成应用程序不同局部或不同零碎之间的信息替换，可分为信息替换架构和路由。
-
信息替换架构 —— 一个发送方和多个接管方之间采纳不同的办法或模式传输信息。
- Pub-Sub(公布 - 订阅) —— 信息由一个发布者依据感兴趣的主题发送给多个接收者(订阅者)。发布者公布特定主题的信息，对这些主题感兴趣的订阅者会收到这些信息，而发送者并不知道具体的接收者是谁。
- Fanout —— 向所有订阅者播送音讯，不思考主题。在这种模式下，发送者发送信息，信息会同时传递给所有连贯的订阅者。
- 单向流 —— 信息流单向流动，通常是从发送方到接管方，不须要任何确认或回复。这是一种单向通信，发送方继续向接管方发送信息流，而不期待接管方回复。
- 双向流 —— 信息在发送方和接管方之间双向流动。
-
路由 —— 确定零碎中发送方和接管方之间如何传递信息。
- Unicast(单播) —— 信息从单个发送者发送到特定接收者。
- Broadcast(播送) —— 向所有连贯的接收器播送信息。
- Multicast(组播) —— 向一组特定的接收者发送信息。
- Anycast(任播) —— 信息从一组潜在接收者中发送到最近的可用接收者。
-
-
架构层 —— 组织分布式系统的组件。
- 显示 / 用户界面层 —— 解决用户交互、向用户显示信息并捕获用户输出。
- 应用层 —— 蕴含零碎的业务逻辑，并协调体现层和畛域层之间的数据流，施行业务规定和流程，这些规定和流程定义了零碎如何运行以及如何与用户交互。
- 业务 / 畛域层 —— 封装系统核心业务逻辑和规定，代表业务畛域的概念模型，并蕴含依据业务需要定义零碎运行形式的逻辑。该层侧重于特定业务的操作和规定。
- 长久层 / 数据拜访层 —— 治理数据库或其余数据源的数据存储和检索，提供与底层数据存储系统交互的必要机制，如执行 CRUD (创立、读取、更新、删除) 操作和数据查问。
- 数据库层 —— 代表理论的数据存储和管理系统，如数据库服务器，解决数据的物理存储。
-
通过提出并答复这四个问题，架构师能够全面理解零碎，确保在设计过程中思考到所有相干方面，有助于明确界定不同层或组件之间的界线，并厘清责任。
要害最佳实际
-
波动性递加准则(The Principle of Diminishing Volatility)
- 依据零碎层的不稳定性或变动的可能性来组织系统层。
- 依据这一准则，可变性或可扭转性应随着设计良好的零碎层数的缩小而升高。
- 客户端层被认为是最不稳固的，因为间接与用户交互，会依据用户的要求频繁更改。
- 应用层的变动基于特定的应用场景，相对来说比客户端层更稳固。
- 引擎层甚至比应用层更稳固，因为变动通常波及根本的业务行为或规定。
- 预计数据拜访层的批改起码，因为解决的是原子操作，如增加、删除、批改和查问数据，这些操作不会常常变动。
-
增量构建准则(Incremental Construction Principle)
- 开发过程分为若干阶段或迭代。增量构建准则主张逐渐构建零碎，在每次迭代中减少新的个性和性能，而不是试图在后期实现整个零碎的设计和施行。
- 初步设计和施行的重点是创立一个满足外围需要的零碎根本版本，而后对该版本进行测试、评估和审查，以收集反馈意见并确定须要改良的中央。依据反馈和评估后果，进行后续迭代，为零碎增加新的或加强性能。
- 增量构建准则通常与 Scrum 或 Kanban 等麻利办法无关，在这些办法中，工作被划分为较小的增量或用户故事，可在短时间内 (通常为几周) 实现。每次迭代都建设在前一次迭代的根底上，逐渐扩大零碎性能。
命名约定
服务 (相当于类) 的命名约定，举荐几条能够进步软件设计清晰度和交换性的准则。
- 服务名称应遵循 Pascal 命名法，也称为 ” 大写驼峰式 ”，即每个单词的第一个字母大写，不应用空格、连字符或下划线。例如，UserService、PaymentManager、OrderEngine 和 ResourceAccessController。
- 服务名应至多由两局部组成，以便更具体的表白服务目标。
- 服务名的后缀应指明服务类型，如管理器 (Manager)、引擎(Engine)、接入(Access) 或资源拜访(ResourceAccess)。
-
服务名的前缀因服务类型而异：
- 对于管理器 (Manager) 类型，前缀应是名词，蕴含一个可扭转的用例。
- 对于引擎 (Engine) 类型，前缀应为定义封装事件的名词。
- 对于资源拜访 (ResourceAccess) 类型，前缀应指明拜访的数据资源。
- 动名词 (以 ”ing” 结尾的动词) 可用作服务名的前缀，但仅限于引擎类型。动名词应代表与协调和拜访可变性无关的性能合成。
- Get 和 Put 等原子操作动词不应作为服务前缀应用，但可用作数据拜访层的接口名称。
参考资料
Programming Naming Conventions – Camel, Snake, Kebab, and Pascal Case Explained
Snake Case VS Camel Case VS Pascal Case VS Kebab Case – What’s the Difference Between Casings?
Pascal case vs. camel case: What’s the difference? | TheServerSide
What Is Pascal Case? Definition & Alternatives (with Examples)
Layered Architecture
Architecture styles – Azure Application Architecture Guide
你好，我是俞凡，在 Motorola 做过研发，当初在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓重的趣味，平时喜爱浏览、思考，置信继续学习、一生成长，欢送一起交流学习。为了不便大家当前能第一工夫看到文章，请敌人们关注公众号 ”DeepNoMind”，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的反对和能源，激励我继续写下去，和大家独特成长提高！
本文由 mdnice 多平台公布