语言 Chinese, Simplified

SEO Title

Software Architecture - The Difference Between Architecture and Design

很多人并不知道软件架构和软件设计之间的区别。即使对开发人员来说，这条线也常常模糊不清，他们可能会混淆软件架构模式和设计模式的元素。作为一名开发人员，我想简化这些概念，并解释软件设计和软件体系结构之间的区别。此外，我将向您展示为什么对开发人员来说了解一点软件体系结构和大量的软件设计是很重要的。所以，让我们开始吧。

软件架构的定义

简单地说，软件体系结构是将软件特性（如灵活性、可伸缩性、可行性、可重用性和安全性）转换为满足技术和业务期望的结构化解决方案的过程。这个定义引导我们去询问软件的特性，这些特性会影响软件架构设计。除了技术要求外，还有一长串主要代表业务或操作要求的特性。

软件架构的特点

如前所述，软件特性描述了软件在操作和技术层面的需求和期望。因此，当产品所有者说他们正在快速变化的市场中竞争时，他们应该迅速调整他们的商业模式。如果一个企业处理需要在短时间内成功完成的紧急请求，那么这个软件应该是“可扩展的、模块化的和可维护的”。作为软件架构师，您应该注意到性能和低容错性、可伸缩性和可靠性是您的关键特征。现在，在定义了前面的特性之后，业务所有者告诉您，他们对该项目的预算有限，这里出现了另一个特性，即“可行性”

在这里您可以找到软件特性的完整列表，也称为“质量属性”。

软件架构模式

大多数人以前可能听说过“微服务”这个词。微服务是许多其他软件架构模式中的一种，如分层模式、事件驱动模式、无服务器模式等等。其中一些将在本文后面讨论。微服务模式在被亚马逊和网飞采用并显示出巨大的影响力后，获得了声誉。现在，让我们深入研究架构模式。

*请注意，不要混淆设计模式，如工厂或适配器模式和架构模式。我稍后再讨论。

无服务器架构

此元素是指依赖第三方服务来管理服务器和后端管理复杂性的应用程序解决方案。无服务器体系结构分为两大类。第一个是“后端即服务（Backend as a service，BaaS）”，第二个是“功能即服务（Functions as a service，FaaS）”，无服务器体系结构将帮助您节省大量时间来处理和修复部署和服务器常规任务的bug。

最著名的无服务器API提供商是Amazon AWS“Lambda”

你可以在这里了解更多。

事件驱动架构

这种体系结构依赖于事件生产者和事件消费者。其主要思想是将系统的各个部分解耦，当另一部分的有趣事件被触发时，每个部分都会被触发。复杂吗？让我们简化一下。假设你设计了一个在线商店系统，它有两个部分。采购模块和供应商模块。如果客户进行了购买，那么采购模块将生成一个“orderPending”事件，因为供应商模块对“orderPending”事件感兴趣，所以它将侦听，以防触发一个事件。一旦供应商模块获得此事件，它将执行一些任务，或者可能触发另一个事件，以便从某个供应商订购更多的产品。

请记住，事件生产者不知道哪个事件消费者在听哪个事件。另外，其他消费者也不知道他们中的哪些人在听哪些事件。因此，主要思想是将系统的各个部分解耦。

如果您有兴趣了解更多信息，请单击此处。

微服务架构

微服务体系结构已经成为最近几年最流行的体系结构。它依赖于开发小型的、独立的模块化服务，其中每个服务解决一个特定的问题或执行一个独特的任务，这些模块通过定义良好的API相互通信以服务于业务目标。我不需要解释更多，只是看看这张图片。

软件设计

软件体系结构负责软件的框架和高级基础设施，而软件设计负责代码级设计，如每个模块在做什么、类的作用域和功能的用途等。

如果您是一名开发人员，了解什么是SOLID原则以及设计模式应该如何解决常规问题对您来说非常重要。

SOLID是指单一责任、开闭、Liskov替换、接口分离和依赖倒置原则。

单一责任原则意味着每一类都必须有一个单一的目的、责任和改变的理由。

开闭原则：类应该为扩展而打开，但为修改而关闭。简单地说，您应该能够向类添加更多功能，但不要以破坏使用它的现有代码的方式编辑当前函数。
Liskov替换原则：这个原则指导开发人员以一种在任何时候都不会破坏应用程序逻辑的方式使用继承。因此，如果名为“XyClass”的子类继承自父类“AbClass”，则子类不应以改变父类行为的方式复制父类的功能。因此，您可以轻松地使用XyClass的对象而不是AbClass的对象，而不会破坏应用程序逻辑。
接口隔离原则：简单地说，因为一个类可以实现多个接口，所以用这样的方式构造代码：一个类永远不会被迫实现一个对其用途不重要的函数。因此，对接口进行分类。
依赖性反转原则：如果您曾经在应用程序开发中遵循TDD，那么您就知道代码的解耦对于可测试性和模块化是多么重要。换句话说，如果某个类“ex:Purchase”依赖于“Users”类，那么用户对象实例化应该来自“Purchase”类之外。

设计模式

Factory模式：

它是OOP世界中最常用的设计模式，因为它在将来修改所使用的类时节省了大量时间。看看这个例子：

假设要实例化Users（）模型类，有两种方法：

1-$users=新用户（）；

2-$users=DataFactory:：get（'users'）；

我更喜欢第二种方式，原因有两个。首先，将类名从“Users”更改为“UsersData”只需要在“数据工厂内部”的一个位置进行一次更改，其余代码将是相同的。其次，如果类用户开始使用Users（$connection）等参数；然后您还需要在一个地方更改它，而不是在每个需要Users对象的函数中。所以，如果你认为第一种方法更好，再想想。