即使在需求管理中考虑了非功能性需求，可维护性和稳健性也很少成为一致实施的核心方面。毕竟，它们很难测试和衡量，如果这方面出现问题，它们只会在很久以后才以技术债务的形式显现出来。也就是说，
当即使是很小的扩展变得越来越复杂或
如果与更改无关的错误发生在软件的完全不同部分。
良好的软件架构的责任不在于客户，而在于软件开发人员。
清洁代码的基础
提前一件事：软件架构应该遵循原则而不是严格的规则。这些原则提 美国电子邮件列表中的牧师 供了开发框架，可以说，是设计软件结构的护栏。由于软件的实际实现是由团队中的开发人员进行的，这也导致了对所开发架构的强烈认同。所有软件开发人员和软件架构师都需要深入研究各自的架构，并找到最好的或至少是最合适的架构。
大家知道，并不是每一个决定都能以基层民主的方式做出。团队中认可的价值观和原则仍然应该体现在决策中。无论如何，这比将架构作为外部严格规范引入开发过程更能提高架构的接受度。
美国软件开发人员和 IT 顾问 Robert C. Martin 的 SOLID 原则已被证明是良好软件架构的起点。它们构成了整个系列原则的核心。首字母缩略词“SOLID”背后的含义可以非常简单快速地解释：
单一责任原则
开闭原则
里氏替换原则
接口隔离原则
依赖倒置原则
由于这五个 SOLID 原则为我们开发软件提供了重要帮助，并且旨在实现良好的面向对象设计，因此我想向您更详细地解释各个术语。
单一责任原则
该原则规定每个组件应该只负责一项任务，并且还应该涵盖一项任务的全部功能。如果对软件进行更改，总是应该有一个原因。实际上，如果用户故事引起的更改仅影响一个组件，则组件的大小是正确的。
开闭原则
开闭原理既可以用于小规模，也可以用于大规模。类的扩展不应该通过改变类来实现，而应该通过继承，或者更好的是通过委托来实现。对于较大的软件单元，插件概念是有意义的，通过它可以添加额外的类来扩展功能。
里氏替换原则
派生类必须始终能够在其基类的上下文中使用。它只能扩展基类的行为，而不能限制它。开发人员在使用它时不应感到任何意外 - 也就是说，无论他们使用的是基类还是派生类。
接口隔离原则
接口的范围由客户端的需求决定，而不是相反。不得强迫客户端实现不需要的功能。这增强了模块的内聚性，但降低了它们的耦合性。
依赖倒置原则
在分层体系结构中，类和模块存在于不同的抽象级别。实现细节（例如数据库连接）封装在较低级别的类中。然而，在更高的层面上，它是关于抽象的业务逻辑。依赖倒置原则指出，较高抽象级别的模块不依赖于较低抽象级别的模块，而应各自引用接口。另一方面，接口不应该依赖于细节，但细节必须依赖于相应的接口。
“干净”的架构
如果考虑到 SOLID 原则，那么这会产生良好的软件架构。如果然后将这些原则与分层架构以及抽象和泛化的原则结合起来，结果就是所谓的干净架构。如下图所示，各个层排列成环形。