软件架构和软件设计的区别

缘起

在日常工作中长说软件架构和软件设计，那么这两者的内容和关系是什么样的，总是傻傻分不清楚，以下通过介绍具体内容对两个领域有初步的认识和了解。

软件架构

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

软件架构特点

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

了解更多软件特性。

软件架构模式

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

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

serverless架构

指的是依赖第三方服务来管理服务器复杂性和后端管理的应用程序的解决方案。无服务器架构分为两大类。第一个是“后端即服务（BaaS）”，第二个是“功能即服务（FaaS）”。无服务器架构将节省大量时间来处理和修复部署和服务器常规任务的错误。最著名的无服务器API供应商是Amazon AWS“lambda”。

了解更多serverless架构。

事件驱动架构

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

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

了解更多事件驱动架构风格

微型服务架构

微服务架构已经成为近几年来最流行的架构。它依赖于开发小型、独立的模块化服务，其中每个服务解决特定的问题或执行独特的任务，并且这些模块通过定义良好的API相互通信，以实现业务目标。

软件设计

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

如果你是一个开发人员，那么了解什么是SOLID的原则以及设计模式应该如何解决常规问题是很重要的。

SOLID是指单一责任、开放封闭、里氏替换、界面分离和依赖倒置原则。

单一责任：意味着每个类必须有一个单一的目标、责任和改变的理由。
开闭原则：一个类应该为扩展而打开，但为修改而关闭。简单地说，您应该能够向类中添加更多的功能，但不要以破坏使用当前函数的现有代码的方式编辑当前函数。
里氏替换原则：这个原则指导开发人员使用继承，以一种不会在任何时候破坏应用程序逻辑的方式。因此，如果名为“bclass”的子类继承自父类“aclass”，则子类不应以更改行为父类的方式复制父类的功能。因此，在不破坏应用程序逻辑的情况下，可以轻松地使用bclass对象而不是aclass对象。
接口分离原则：简单地说，由于一个类可以实现多个接口，那么以一个类永远不会被强制实现对其用途不重要的函数的方式构造代码。所以，对接口进行分类。
依赖倒置原则：如果你曾经在应用程序开发中实践过TDD，那么就知道分离代码对于可测试性和模块化多重要。换句话说，如果某个类“ex:purchase”依赖于“users”类，那么用户对象实例化应该来自“purchase”类之外。

设计模式

工厂模式

是OOP中最常用的软件设计模式，因为当你必须修改所使用的某个类时，它会节省很多时间。

假设您想实例化一个users（）模型类，有两种方法可以做到：

1 2	$users=new users(); $users=datafactory::get('users');

我更喜欢第二种方法，有两个原因。首先，将类名从“users”更改为“users data”只需要在“数据工厂内”的一个位置进行一次更改，其余代码将相同。其次，如果类用户开始使用用户（$connection）等参数，那么您还需要在一个位置更改它，而不是在每个需要用户对象的函数中更改它。所以，如果你认为第一种方法更好，可以再想想迭代时需要规范重构某个类名多么胆战心惊。