这类系统包括提供给用户操作的、运行于浏览器中、具有 UI 的业务逻辑展示和输入部分，运行于服务器端、用后端编程语言构建的业务逻辑处理部分，以及用于存储业务数据的关系数据库或其他类型的存储软件。
根据软件系统在运行期的表现风格和部署结构，我们可以粗略地将其划分为两大类。
（1）整个系统的所有功能单元，整体部署到同一个进程（所有代码可以打包成 1 个或多个文件），我们可以称之为 “单体架构”（Monolithic Architecture）；
（2）整个系统的功能单元分散到不同的进程，然后由多个进程共同提供不同的业务能力，我们称之为 “分布式架构”（Distributed Architecture）。
再结合软件系统在整个生命周期的特点，我们可以进一步区分不同的架构风格。
对于单体架构，我们根据设计期和开发实现期的不同模式和划分结构，可以分为：
简单单体模式：代码层面没有拆分，所有的业务逻辑都在一个项目（Project）里打包成一个二进制的编译后文件，通过这个文件进行部署，并提供业务能力；
MVC 模式：系统内每个模块的功能组件按照不同的职责划分为模型（Model）、视图（View）、控制器（Controller）等角色，并以此来组织研发实现工作；
前后端分离模式：将前后端代码耦合的设计改为前端逻辑和后端逻辑独立编写实现的处理模式；
组件模式：系统的每一个模块拆分为一个子项目（SubProject），每个模块独立编译打包成一个组件，然后所有需要的组件一起再部署到同一个容器里；
类库模式：A 系统需要复用 B 系统的某些功能，这时可以直接把 B 系统的某些组件作为依赖库，打包到 A 系统来使用。
对于分布式架构，我们根据设计期的架构思想和运行期的不同结构，可以分为：
面向服务架构（Service Oriented Architecture）：以业务服务的角度和服务总线的方式（一般是 WebService 与 ESB）考虑系统架构和企业 IT 治理；
分布式服务架构（Distributed Service Architecture）：基于去中心化的分布式服务框架与技术，考虑系统架构和服务治理；
微服务架构（MicroServices Architecture）：微服务架构可以看做是面向服务架构和分布式服务架构的拓展，使用更细粒度的服务（所以叫微服务）和一组设计准则来考虑大规模的复杂系统架构设计。
也有人把如上的各个架构风格总结为四个大的架构发展阶段：
（1）单体架构阶段
（2）垂直架构阶段
（3）SOA 架构阶段
（4）微服务架构阶段
这种分类跟前述的方式并没有多大区别。我们接下来详细介绍其中的一些重要架构风格。
单体架构：简单单体模式
简单单体模式是最简单的架构风格，所有的代码全都在一个项目中。这样研发团队的任何一个人都可以随时修改任意的一段代码，或者增加一些新的代码。
开发人员也可以只在自己的电脑上就可以随时开发、调试、测试整个系统的功能。
也不需要额外的一些依赖条件和准备步骤，我们就可以直接编译打包整个系统代码，创建一个可以发布的二进制版本。
这种方式对于一个新团队的创立初期，需要迅速开始从 0 到 1，抓住时机实现产品最短时间推向市场，可以省去各种额外的设计，直接上手干活，争取了时间，因而是非常有意义的。
但是这种方式对于一个系统的长期稳定发展确实有很多坏处的。
首先，简单单体模式的系统存在代码严重耦合的问题。所有的代码都在一起，就算是按照 package 来切分了不同的模块，各不同模块的代码还是可以直接相互引用。
这就导致了系统内的对象间依赖关系混乱，修改一处代码，可能会影响一大片的功能无法正常使用。
第二，简单单体模式的系统变更对部署影响大，并且这个问题是所有的单体架构系统都存在的问题。
系统作为一个单体部署，每次发布的部署单元就是一个新版本的整个系统，系统内的任何业务逻辑调整都会导致整个系统的重新打包，部署、停机、再重启，进而导致了系统的停机发布时间较长。
每次发布上线都是生产系统的重大变更，这种部署模式大大提升了系统风险，降低了系统的可用性。
第三，简单单体模式的系统影响开发效率。