chinese philosophy
背景介绍
张建飞软件教练, 代码精进之路，程序员的底层思维，cola框架 作者 从码农到工匠 公众号
- 灵感来源
A philosophy of software design
简单总结
哲学
| 黄金分割点 | vs | 中庸 |
|---|---|---|
| 0.618定义抽象 | 本质 | 两端未是不中(极端事情极端对待) |
| 注重推理 | 指导 | 形而上学(博学之，有弗学，学之弗能，弗措也) |
API设计中的抽象层次权衡
抽象 vs 具体
| 极端可扩展方案 | 折中方案 | 极端不可扩展方案 |
|---|---|---|
| all Map item | some map some item | all item value |
| 网关不需要管，透传 | 当前确定，但未来不确定 | 通信协议 |
任何实体都会体现出抽象的层次性：
抽象层次越高，越灵活 抽象层次越低，越明确
eat red apple => eat apple => eat fruit => get su => eat thing
Reuse vs Repeat
| reuse | vs | repeat |
|---|---|---|
| 引入耦合 | 问题 | 解耦 |
| 平台化耦合 | 例子 | 抽象共性，组件，解决方案库 |
reuse的代价：耦合
Waterful vs Agile
| Waterful | vs | Agile |
|---|---|---|
| 战略 | 本质 | 战术 干就完了 |
| 注重设计 | Good | 注重实践 |
end: 增量迭代
100% Coverage vs No test
写多少测试才算充分
I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence
50-60% -> no docrine
Kent Beck TDD创始人
TDD 芝加哥學派 vs TDD 伦敦学派
chicago school 至底向上
提倡推迟设计，等所有信息get,不得不决策; inside out, bottom up
London school 至顶向下
我们没有完美的架构可以快速直接完成，需要迭代，outside in, top bottom
真实情况
inside out + outside in, bottom up + top down
贫血 or 充血
事务脚本模式：补血
过犹不及: 抽血
关键是健康，共性的东西就可以沉淀到领域层 循序渐进沉淀领域能力：1.内聚，2.复用，3.可理解
以客户注册为例子： 先把App做厚，把整体业务覆盖 沉淀领域业务， 领域是POJO的，可测试性非常好 对于外领域，通过gateway进行防腐
通常不建议将仓储层的操作放到领域服务中，因为这会违反职责分离的原则。 领域服务应该专注于业务逻辑，而数据持久化的操作应该由应用服务来处理。 不过，如果你确实有特殊需求，可以通过依赖注入的方式将仓储接口传递给领域服务， 但这应当谨慎使用，并且要确保领域服务的主要职责仍然是处理业务逻辑。
单体 vs 微服务
分布式单体陷阱
服务划分的考量维度：
功能维度：
业务内聚性 核心域，通用域
非功能维度：
可靠性 性能 易变性
组织维度：
组织结构 人员数 工期 业务发展
如果不能正确的构建大型单体应用，那么微服务也帮不了你