《架构整洁之道》之整洁的嵌入式架构

Doug观点:
虽然软件本身并不会随时间推移而磨损,但硬件及其固件却会随时间推移而过时,随即也需要对软件做相应改动。

Bob基于Doug观点补充:
虽然软件质量本身并不会随时间推移而损耗,但是未妥善管理的硬件依赖和固件依赖却是软件的头号杀手。

《架构整洁之道》之测试边界

一、测试也是一种系统组件

测试组件通常是一个系统中最独立的组件。系统的正常运行并不需要用到测试组件,用户也不依赖于测试组件。测试组件的存在是为了支持开发过程,而不是运行过程。然而,测试组件仍然是系统中不可或缺的一个组件。事实上,测试组件在许多方面都反映了系统中其他组件所应遵循的设计模式。

《架构整洁之道》之服务:宏观与微观

一、面向服务的架构

“只要使用了服务,就等于有了一套架构”这种思想。显然是错误的。
如前面所说,架构设计的任务就是找到高层策略与低层细节之间的架构边界,同时保证这些边界遵守依赖关系规则。所谓的服务本身只是一种比函数调用方式成本稍高的,分割应用程序行为的一种形式,与系统架构无关。

《架构整洁之道》之Main组件

一、最细节化的部分

Main组件是系统中最细节化的部分,也就是底层的策略,它是整个系统的初始点。在整个系统中,除了操作系统不会再有其他组件依赖于它了。Main组件的任务是创建所有的工厂类、策略类以及其他的全局设施,并最终将系统的控制权转交给最高抽象层的代码来处理。

Main组件中的依赖关系通常应该由依赖注入框架来注入。在该框架将依赖关系注入到Main组件之后,Main组件就应该可以在不依赖于该框架的情况下自行分配这些依赖关系了。

《架构整洁之道》之不完全边界

构建完整的架构边界是一件很耗费成本的事。在这个过程中,需要为系统设计双向的多态边界接口,用于输入和输出的数据结构,以及所有相关的依赖关系管理,以便将系统分割成可独立编译与部署的组件。这里会涉及大量的前期工作,以及大量的后期维护工作。

《架构整洁之道》之展示器和谦卑对象

一、谦卑对象模式

谦卑对象模式最初的设计目的是帮助单元测试的编写者区分容易测试的行为与难以测试的行为,并将它们隔离。其设计思路非常简单,就是将这两类行为拆分成两组模块或类。其中一组模块被称为谦卑组,包含了系统中所有难以测试的行为,而这些行为已经被简化到不能再简化了。另一组则包含了所有不属于谦卑对象的行为。

《架构整洁之道》之尖叫的软件架构

一、架构设计的主题

架构设计不是与框架相关的,这件事不应该是基于框架来完成的。对于我们来说,框架只是一个可用的工具和手段,而不是一个架构所规范的内容。如果我们的架构是基于框架来设计,它就不能基于我们的用例来设计了。