架构的尖叫

本文探讨了软件架构的本质,强调架构应当围绕用例而非框架构建。好的架构不仅能够支持系统的功能需求,还能灵活应对技术选型的变化。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Screaming Architecture
架构的尖叫

    uncle bob
    30 Sep 2011
    Architecture


Imagine that you are looking at the blueprints of a building. This document, prepared by an architect, tells you the plans for the building. What do these plans tell you?
想象你正在看一栋建筑的蓝图,这份由架构师准备的文档告诉了你整个建筑的规划。那么这些规划会告诉你什么呢?

If the plans you are looking at are for a single family residence, then you’ll likely see a front entrance, a foyer leading to a living room and perhaps a dining room. There’ll likely be a kitchen a short distance away, close to the dining room. Perhaps a dinette area next to the kitchen, and probably a family room close to that. As you looked at those plans, there’d be no question that you were looking at a house. The architecture would scream: house.

如果你看到的规划是一个单一的家庭住宅,那么你可能会看到一个前门,一个通向客厅的休息室,也许是一个饭厅。可能还有一个离餐厅很近的厨房。也许厨房旁边可能是餐桌,家庭室可能很近。当你看那些规划时,毫无疑问可以确认你是在看房子。架构会尖叫:房子。

Or if you were looking at the architecture of a library, you’d likely see a grand entrance, an area for check-in-out clerks, reading areas, small conference rooms, and gallery after gallery capable of holding bookshelves for all the books in the library. That architecture would scream: Library.

或者你正在看一座图书馆的规划。你可能会看到一个大入口,一个供登记的区域,阅读区,小会议室,以及一排排的放满书的书架。那个建筑会尖叫:图书馆。

So what does the architecture of your application scream? When you look at the top level directory structure, and the source files in the highest level package; do they scream: Health Care System, or Accounting System, or Inventory Management System? Or do they scream: Rails, or Spring/Hibernate, or ASP?

那么你的应用程序的架构会尖叫什么呢?当您查看顶层目录结构和高层包中的源文件时,它们会尖叫:医疗系统、会计系统或库存管理系统吗?或者他们尖叫:Rails,或Spring,Hibernate,或者ASP?

The Theme of an Architecture
架构的主题


Go back and read Ivar Jacobson’s seminal work on software architecture: Object Oriented Software Engineering. Notice the subtitle of the book: A use case driven approach. In this book Ivar makes the point that software architectures are structures that support the use cases of the system. Just as the plans for a house or a library scream about the use cases of those buildings, so should the architecture of a software application scream about the use cases of the application.
回溯并翻阅Jacobson的软件架构方面的开创性工作:面向对象的软件工程。注意书的副标题:用例驱动的方法。在这本书中,Ivar提出软件架构是指能够支撑系统所有用例的结构的观点。正如房屋或图书馆的规划对这些建筑物的用例尖叫一样,软件应用程序的架构也会对应用程序的用例进行尖叫。


Architectures are not (or should not) be about frameworks. Architectures should not be supplied by frameworks. Frameworks are tools to be used, not architectures to be conformed to. If your architecture is based on frameworks, then it cannot be based on your use cases.

架构不是(或者不应该是)关于框架的。架构不应该通过框架来提供。框架仅仅是使用的工具,而不是被确认的架构。如果你的架构是基于框架的,那么它就没法基于你的用例。

The Purpose of an Architecture

架构的目的

The reason that good architectures are centered around use-cases is so that architects can safely describe the structures that support those use-cases without committing to frameworks, tools, and environment. Again, consider the plans for a house. The first concern of the architect is to make sure that the house is usable, it is not to ensure that the house is made of bricks. Indeed, the architect takes pains to ensure that the homeowner can decide about bricks, stone, or cedar later, after the plans ensure that the use cases are met.
好的架构聚焦于用例的原因是,如此一来,架构就可以安全地描述支撑用户的结构而不用关心框架,工具和环境。再说一遍,就像房屋的规划一样。架构第一个要关心的,是确保房子是可用的,而不是房子是由砖头垒成的。事实上,架构要在努力确保房主的用例可以满足的前提下,再在稍后的规划中做砖块、石头或雪松的决定。

A good software architecture allows decisions about frameworks, databases, web-servers, and other environmental issues and tools, to be deferred and delayed. A good architecture makes it unnecessary to decide on Rails, or Spring, or Hibernate, or Tomcat or MySql, until much later in the project. A good architecture makes it easy to change your mind about those decisions too. A good architecture emphasizes the use-cases and decouples them from peripheral concerns.

一个好的软件架构允许框架、数据库、Web服务器以及其他环境问题和工具的决定可以被推迟和延迟。一个好的架构使得项目不必取决于Rails、Spring、Hibernate、Tomcat或MySQL,这些因素可以在项目后期阶段解决。一个好的架构也能很容易地改变这些决策。一个好的架构强调用例,以及用例和外围的解耦。


But what about the Web?

但Web又是什么情况呢?

Is the web an architecture? Does the fact that your system is delivered on the web dictate the architecture of your system? Of course not! The Web is a delivery mechanism, and your application architecture should treat it as such. The fact that your application is delivered over the web is a detail and should not dominate your system structure. Indeed, the fact that your application is delivered over the web is something you should defer. Your system architecture should be as ignorant as possible about how it is to be delivered. You should be able to deliver it as a console app, or a web app, or a thick client app, or even a web service app, without undue complication or change to the fundamental architecture.

Web是个架构吗?允许在web上交付应用会决定你系统的架构吗?当然不是。web只是一个交付的机制,你的应用架构也应该这样对待web。事实上,你的应用是否在web上交付是个很细节的问题,并且不应支配你的系统结构,更进一步,你的应用是否在web上交付应该是一个延迟决策。你的系统架构应该忽略掉它怎么交付。你应该能够通过诸如控制台应用,web应用或者瘦客户端,甚至是web service应用等来交付,而不会对基础架构造成不必要的复杂性或更改。


Frameworks are tools, not ways of life.
框架是工具而不是生活方式


Frameworks can be very powerful and very useful. Framework authors often believe in their frameworks. The examples they write for how to use their frameworks are told from the point of view of a true believer. Other authors who write about the framework also tend to be disciples of the true belief. They show you the way to use the framework. Often it is an all-encompassing, all-pervading, let-the-framework-do-everything position. This is not the position you want to take.

框架是威力强大而且用途颇广的。框架的作者经常迷信于他们的杰作。他们往往从一个虔诚信徒的角度来编写如何使用他们的框架的demo。写这个框架的其他作者也往往是虔诚信徒的门徒。他们向你展示如何使用框架。通常来说,它是包罗万象的,无孔不入的,它可以做一切事情。这不是你想要的角度。

Look at each framework with a jaded eye. View it skeptically. Yes, it might help, but at what cost. How should I use it, and how should I protect myself from it. How can I preserve the use-case emphasis of my architecture? How can I prevent the framework from taking over that architecture.

用一只疲惫的眼看看每个框架。用质疑的眼光看看它。是的,它可能是有帮助的,但要知道它的代价。我应该怎么用它,我应该怎么和它保持距离?我怎么保护我的架构中的重点用例?我怎么阻止框架渗透到架构中?


Testable Architectures.
可测试的架构


If you system architecture is all about the use cases, and if you have kept your frameworks at arms-length. Then you should be able to unit-test all those use cases without any of the frameworks in place. You shouldn’t need the web server running in order to run your tests. You shouldn’t need the database connected in order to run your tests. Your business objects should be plain old objects that have no dependencies on frameworks or databases or other complications. Your use case objects should coordinate your business objects. And all of them together should be testable in-situ, without any of the complications of frameworks.

如果你的系统架构全是关于用例的,并且如果你已经和你的框架保持一臂距离,那么你应该不使用任何框架就能够单元测试所有的用例。你不应该需要web服务器去跑你的测试,你不应该需要数据库连接去跑你的测试。你的业务对象应该不依赖框架或者数据库或者其他并发体。你的用例对象应该和你的业务对象协同。所有的业务应该是独立可测试的,不依赖于任何的框架。

Conclusion
结论


Your architectures should tell readers about the system, not about the frameworks you used in your system. If you are building a health-care system, then when new programmers look at the source repository, their first impression should be: “Oh, this is a heath-care system”. Those new programmers should be able to learn all the use cases of the system, and still not know how the system is delivered. They may come to you and say: “We see some things that look sorta like models, but where are the views and controllers”, and you should say: “Oh, those are details that needn’t concern you at the moment, we’ll show them to you later.”

你的架构应该把系统告诉给读者,而不是你的系统使用的框架。如果你正设计一个医疗系统,当新手看到源码结构的时候,他们的第一印象应该是:“喔,这是一个医疗系统。”那些新手应该能够从系统中学到所有的用例,但可能还不清楚系统是如何交付的。他们来到你面前,说:“我们看到了一些东西,看起来有点像模型,但视图和控制器在哪里?”你应该说:“哦,这些都是细节,当前你们不用关心,我们以后会告诉你们。”
<think>好的,我现在需要设计一个实时声音事件检测系统的架构。首先,我得了解这个系统的主要需求是什么。实时处理是关键,所以延迟必须很低。同时,系统需要能够准确识别各种声音事件,比如警报声、玻璃破碎声等。可能还需要考虑环境噪声的影响,以及如何处理不同的音频输入源。 接下来,我应该参考已有的架构设计模型,比如ABSDM提到的体系结构需求、设计、文档化等阶段[^1]。首先进行需求分析,明确系统的功能和非功能需求。例如,用户需求分析阶段要确定信息处理要求和系统边界,如引用[2]中提到的,需要综合用户的应用需求,明确新系统的功能[^2]。 然后,架构设计部分可能需要分层次处理。比如,音频采集层负责接收实时音频流,预处理层进行降噪和特征提取,核心检测层使用机器学习模型进行分类,后处理层优化结果,最后是输出和响应层。每个层次之间如何交互,数据流的处理方式都需要考虑。 在技术选型方面,音频预处理可能需要使用FFT或者MFCC等特征提取方法。模型方面,深度学习模型如CNN或RNN可能适用,但实时性要求可能需要轻量级模型,比如MobileNet或特定的时序模型。此外,边缘计算设备的选择也很重要,比如使用树莓派还是更专业的硬件。 还需要考虑系统的可扩展性和维护性。比如,是否支持模型的热更新,如何监控系统性能,日志记录和错误处理机制。这些都是架构设计中不可忽视的部分。 可能遇到的问题包括实时性无法满足,如何处理高并发音频流,模型准确率与延迟的平衡,以及不同环境下的适应性。需要设计相应的解决方案,比如优化算法复杂度,引入多线程处理,或者使用分布式架构分担负载。 最后,文档化和测试阶段需要输出体系结构规格说明和质量设计说明书,确保每个模块的功能和接口定义清晰,便于后续开发和维护。</think>### 实时声音事件检测系统架构设计方案 #### 一、系统需求分析 1. **功能需求** - 实时采集音频流(采样率≥16kHz) - 支持环境噪声抑制与特征提取(如梅尔频率倒谱系数$MFCC$) - 声音事件分类(如枪声、尖叫、玻璃破碎等) - 低延迟响应(端到端延迟≤200ms) - 支持多设备接入与分布式部署 2. **非功能需求** - 可靠性:误报率≤3%,漏报率≤1% - 可扩展性:支持模型热更新与动态负载均衡 - 安全性:数据加密传输与访问控制 #### 二、架构设计 $$系统架构 = \begin{cases} \text{音频采集层} & \text{(设备端)} \\ \text{预处理层} & \text{(边缘计算)} \\ \text{核心检测层} & \text{(云端/本地服务器)} \\ \text{后处理层} & \text{(决策引擎)} \\ \text{输出响应层} & \text{(告警/日志)} \end{cases}$$ (符合ABSDM体系结构设计阶段的模块化原则[^1]) #### 三、核心模块实现 1. **音频预处理** - 降噪算法:谱减法$S(f)=|Y(f)|^2 - |N(f)|^2$ - 特征提取:通过短时傅里叶变换生成$MFCC$特征向量 2. **检测模型设计** ```python # 使用轻量级时序卷积网络 model = Sequential([ Conv1D(64, 3, activation='relu', input_shape=(40, 1)), # MFCC特征维度40 MaxPooling1D(2), Bidirectional(LSTM(32)), Dense(len(CLASSES), activation='softmax') ]) ``` 3. **实时处理流程** $$延迟优化模型: T_{total} = T_{采集} + T_{传输} + \lceil \frac{T_{处理}}{窗口长度} \rceil$$ #### 四、关键技术选型 | 模块 | 技术方案 | 性能指标 | |------|----------|----------| | 边缘计算 | NVIDIA Jetson Nano | 472GFLOPS | | 传输协议 | WebRTC | 端到端延迟<100ms | | 模型部署 | TensorRT优化 | 推理速度提升3-5倍 | #### 五、验证与测试 1. **测试数据集** - UrbanSound8K(10类城市环境音) - 自建工业场景数据集(包含机械故障音频) 2. **性能验证** $$准确率指标: F1 = 2 \times \frac{precision \times recall}{precision + recall} \geq 0.92$$ #### 六、演进方向 1. 联邦学习实现多设备协同训练 2. 基于知识蒸馏的模型轻量化 3. 声纹识别与事件检测的联合建模
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值