关于架构
问题
通常，当由于项目中的某些问题导致开发停止时，就会提出关于架构的讨论。
Bus-factor 和入职
只有有限的人数理解项目及其架构
示例：
- "很难将一个人加入开发中"
- "对于每个问题，每个人都有自己的解决方案意见"（让我们嫌妒 angular）
- "我不理解这个大型单体块中发生了什么"
隐式和不可控制的后果
开发/重构过程中有很多隐式的副作用 （"一切都依赖于一切"）
示例：
- "feature 导入 feature"
- "我更新了一个页面的 store，另一个页面的功能就失效了"
- "逻辑散布在整个应用程序中，无法追踪哪里是开始，哪里是结束"
不可控制的逻辑重用
很难重用/修改现有逻辑
同时，通常存在两个极端：
- 要么为每个模块完全从头开始编写逻辑 （在现有代码库中可能存在重复）
- 要么倾向于将所有实现的模块转移到
shared文件夹，从而创建一个大型的模块转储场 （其中大多数只在一个地方使用）
示例：
- "我的项目中有 N 个相同业务逻辑的实现，我仍然在为此付出代价"
- "项目中有 6 个不同的按钮/弹窗/... 组件"
- "helpers 的转储场"
需求
因此，提出理想架构的期望需求似乎是合乎逻辑的：
备注
无论何处提到"容易"，都意味着"对广泛的开发者来说相对容易"，因为很明显不可能为绝对所有人制作理想的解决方案
明确性
- 应该易于掌握和解释项目及其架构给团队
- 结构应该反映项目的真实业务价值
- 抽象之间必须有明确的副作用和连接
- 应该易于检测重复逻辑而不干扰独特实现
- 项目中不应该有逻辑分散
- 对于良好的架构，不应该有太多异构抽象和规则
控制
- 良好的架构应该加速任务解决和功能引入
- 应该能够控制项目的开发
- 应该易于扩展、修改、删除代码
- 必须遵守功能的分解和隔离
- 系统的每个组件都必须易于替换和移除
适应性
- 良好的架构应该适用于大多数项目
- 具有现有基础设施解决方案
- 在开发的任何阶段
- 不应该依赖于框架和平台
- 应该能够轻松扩展项目和团队，具有开发并行化的可能性
- 应该易于适应不断变化的需求和环境