这是我参与「第四届青训营 」笔记创作活动的第14天

客户端架构设计及应用

常见的架构手段

• 不同架构手段的共同目标是高内聚低耦合

• 找到适合业务场景的架构而不是炫技滥用

• 一个复杂的系统是多种架构模型的组合体

架构演进的例子

• 架构随业务发展由简单变得复杂是规律

• 没必要最初用复杂架构来解决简单问题

• 需要用规范持续重构来对抗代码的腐朽

框架总结比较

架构模型	优点	缺点
MVC	模块职责划分明确。主要划分层MVC三个模块，利于代码的维护。	View和Controller容易膨胀。 View与Model没有完全分离
MVP	View与Model完全分离，可以修改试图而不影响模型，交互都发生在 Presenter Presenter与View的交互式通过接口来进行的，方便单元测试	页面逻辑复杂的化，相应的接口也回变多，增加维护成本
MVVM	ViewModel与View的耦合更彻底，ViewModel只负责处理和提供数据。 ViewModel 里面只包含数据和业务逻辑，没有UI，方便单元测试	数据绑定使得程序较难调试，因为数据都是自动更新到UI

另外还可以将 Controller 层的业务代码分离出来，做一个 Service 层，单独处理业务逻辑

AOP例子

所有人都得吃饭，吃饭就是一个切面

成为优秀架构师

• 定义问题 → 确定架构 → 方案落地 → 结果复盘

• 架构的问题是盘根错节的，将所有问题放在一起，就有轻重缓急之分，就有类别之分

• 挑战、问题、手段这些经常混为一谈，哪些是挑战？哪些是问题？那些是手段？

• 勤于编码，有技术追求

QA

1. 想问下 DDD（领域驱动设计） 指导代码落地难度如何？会不会导致过度设计问题？（因为之前看博客有说 DDD 就是拿来忽悠客户的）

反正回答，确实是，本质上是信息的不对称

《显然会啊》

是容易的，编码不会是障碍。要定义好DSL 描述语言，双方达成共识

2. 想问下如果架构设计过于复杂，会不会遇到想要优化看起来蛮小的功能，但是实际上手，发现涉及到非常多方面的代码，实现难度提高的情况，反过来如果有这种情况出现，是不是表明项目里存在一定设计不合理的情况？

保持敬畏

看到不爽的地方不要漠视它

大胆猜测，小心验证

3. 如何避免过度设计？

首先从心态上摆正，不要炫技，多学习

4. 函数嵌套问题

没必要过度拆函数

还是要拆

比如回调地狱（一路回调三四级）

了解事件驱动的设计