前言
我大概在刚刚开始进行软件架构设计的时候，接触到了clean architect的架构思想和方式。刚开始进行架构设计的时候，还停留在模块，分层之类的基本元素的组合上，所以当时也寻找一些业界比较好的方法论，综合实践看下，clean architect和SOLID是最佳的设计原则。 SOLID 是以下是原则的缩写：
- S 单一职责原则
- O 开闭原则
- L 里氏替换原则
- I 接口隔离原则
- D 依赖倒置原则
正文
clean architect
在实践中，我认为践行clean architecture的关键是依赖规则。这条规则规定源代码只能向内依赖，在最里面的部分对外面一点都不知道，也就是内部不依赖外部，而外部依赖内部。这种依赖包含代码名称，或类的函数，变量或任何其他命名软件实体。 同样，在外面圈中使用的数据格式不应被内圈中使用，特别是如果这些数据格式是由外面一圈的框架生成的。我们不希望任何外圆的东西会影响内圈层。
外圈通常是应用层的最上层，比如UI层； 内圈通常是应用层的最底层，比如数据层，data center这种entities
Clean Architecture 和 MVVM
在实践中，有界面的应用因为需要设计view mode，故通常需要结合clean architecture和MVVM进行架构设计。
从整个应用程序的功能层级来看，分为UI层，业务层，数据层部分，其中数据层，业务层可以在项目间复用，UI层根据不同的项目定义，开放修改。 从依赖视角来看，UI层到业务层，业务层到数据层，层层单向依赖。 从数据视角来看，数据从底层传入后，经由数据层，业务层，UI层，层层对数据进行处理加工。
能够重用的代码（即Business Use Cases和Data层）即是整体软件架构平台层中的业务基础部分，这部分代码可以在不同的项目中复用，可以加速应用层的开发工作。
需要考虑的3个方面
- 功能性需求：功能模块，层次化，交互
- 非功能性需求： 性能， 复用， 质量
- 生命周期： 扩展， 重构，集成
表现类型
- 业务逻辑架构： 业务实现，功能划分，与需求中要求的功能和业务紧密联系
- 技术实现架构： 功能聚合，层次划分，与详设中的模块紧密联系
- 静态架构： 层次机构， 功能模块，接口关系
- 动态架构： 复杂功能， 状态控制， 数据流动， 中断处理，时间管理，资源管理
设计视角
- 架构对外：功能， 接口， 环境影响
- 对内： 静态结构， 动态行为， 资源配置
- 设计限制： 非功能性需求， 资源限制
评估准则
- 可行性
- 时间，成本
- 可扩展性
- 平台化 以上这些因素，都可以成为最终采用购买，自研开发还是重用的评估输入
测试
我认为可以通过集成测试来对架构进行闭环验证
- 按照架构设计定义的模块或者组件进行集成，集成到更大的软件项，直至到和架构设计完全一致的软件项
- 通过接口测试来验证架构设计中定义的接口
- 交互测试，对应架构中的动态行为
- 功能测试，对应架构设计中的功能模块定义和约束（在功能模块中需要明确该模块实现的功能）
多态
- 动态多态
- 静态多态：采用模板递归模式(CRTP)
- C++中的返回值优化（Return Value Optimization, RVO）和移动语义，避免了右值（即临时对象）复制的过程。
结束
好了，今天暂时更到这，欢迎大家阅读、批评和指正，下回再见。
