系统架构设计师—案例分析—架构设计

文章目录

• 经典架构风格对比
• • 面向对象架构风格/显示调用风格
  • • 优点
    • 缺点
    • 举例
  • 事件驱动的系统/隐式调用风格
  • • 优点
    • 缺点
    • 举例
  • 基于规则的系统架构风格
  • • 优点
    • 缺点
    • 举例
  • 管道过滤器风格
  • • 优点
    • 缺点
    • 举例
  • 仓库风格
  • • 优点
    • 缺点
    • 举例
  • 解释器风格
  • • 优点
    • 缺点
    • 举例
  • 分层架构风格
  • • 优点
    • 缺点
    • 举例

经典架构风格对比

面向对象架构风格/显示调用风格

优点

1. 一个对象对外隐藏了自己的详细信息。
2. 对象将数据和操作封装在一起。
3. 继承和封装方法为对象复用提供了技术支持。

缺点

1. 如果一个对象要调用另一个对象，则必须知道它的标识和名称。

举例

一般业务系统

事件驱动的系统/隐式调用风格

优点

1. 事件发布者不需要知道哪些构件会响应事件。

缺点

1. 构件放弃了对计算的控制权，完全由系统来决定。
2. 存在数据传输的问题。

举例

消息队列

基于规则的系统架构风格

优点

1. 规则数据可以动态更改，灵活性好。
2. 定义新的规则，即可扩展。

缺点

1. 实时解释规则，性能较差。

举例

规则引擎

管道过滤器风格

优点

1. 简单性。
2. 支持复用。
3. 便于系统分析。

缺点

1. 不适合用来设计交互式应用系统。
2. 由于没有通用的数据传输标准，因此每个过滤器都需要解析输入数据和合成数据。
3. 难以进行错误处理。

举例

流程引擎

仓库风格

优点

1. 便于多客户共享大量数据，而不必关心数据时何时产生的，由谁提供的，通过何种途径来提供。

缺点

1. 对共享数据结构，不同知识源要达成一致。
2. 需要同步机制和加锁机制来保证数据的完整性和一致性，增大了设计的复杂度。

举例

数据仓库

解释器风格

优点

1. 可移植性好。

缺点

1. 由于使用了特定语言和自定义操作规则，因此增加了系统运行的开销。
2. 解释器系统难以设计和测试。

举例

编译器

分层架构风格

优点

1. 设计者可以将系统分解为一个增量的步骤序列，从而完成复杂的业务逻辑。
2. 每一层最多和相邻的上下两层进行交互，只给相邻层提供相同的接口。

缺点

1. 并非所有系统都能够按照层次来进行划分。
2. 很难找到一种合适和正确的层次划分方法。
3. 传输数据需要经过多个层次。
4. 多层结构难以调试。

举例

OSI协议，MVC架构，DDD架构，Cola架构。