面向对象分解
用来支持功能性需求、系统应该被拆分为哪些问题域、对象
关注软件模块组织和开发环境上、从组件、模块、子系统的组织和分层
每一层为上层提供有限的良好定义的接口供调用
团队结构
开发流程
测试计划
项目协作工具
Road Map 发布计划
1.2.7 处理视图关注进程、线程、对象等运行的概念，以及相关的并发、同步、通信等问题
从软件实现的角度去关注非功能性需求
单体从硬件角度去关注非功能属性
单体巨大的代码库
过载的 IDE
过载的 WEB 容器
持续部署困难
应用扩展困难
难于进行规模化开发
模式: 单体架构https://microservices.io/patterns/cn/monolithic.html
1.3.2 高可用架构 系统设计故障转移
超时控制
降级和限流
系统运维灰度发布
故障演练
故障转移 完全对等的节点之间做故障转移在对等节点之间做故障转移，相对来说简单些
在这类系统中所有节点都承担读写流量，并且节点中不保存状态，每个节点都可以作为另一个节点的镜像
不对等的节点之间，即系统中存在主节点也存在备节点使用最广泛的故障检测机制是“心跳”
你可以在客户端上定期地向主节点发送心跳包，也可以从备份节点上定期发送心跳包
当一段时间内未收到心跳包，就可以认为主节点已经发生故障，可以触发选主操作
超时/降级/限流 数据库访问超时、rpc/远程调用超时、缓存/队列等其他中间件访问超时 探测出系统或者服务单位内允许出现的最大请求，直接拒绝后面的请求 水平/垂直扩展水平（也叫横向扩展）：用更多的节点支撑更大的请求
如成千上万的蚂蚁完成一项搬运工作
垂直（也叫纵向扩展）：扩展一个点的能力支撑更大的请求
如利用一个人的能力，如蜘蛛侠逼停火车
AKF 扩展立方X 轴：代表无差别的克隆服务和数据，工作可以很均匀的分散在不同的服务实例上
Y 轴：关注应用中职责的划分，比如数据类型，交易执行类型的划分
Z 轴：关注服务和数据的优先级划分，如分地域划分
业务模块化打造单体和分布式部署同步支持方案https://mp.weixin.qq.com/s/HE7BxH_RZo45bY2baNgt5Q
模块拆分原则微服务拆分的大部份原则依旧适用
一个业务模块对应一个数据库，不能直接查另一个业务模块的数据库
模块之间的调用通过抽象契约接口来完成
模块之间互相依赖只能依赖于抽象契约
1.3.3 云原生 什么是云原生云原生技术有利于各组织再公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用
云原生的代表技术包括容器、微服务、服务网络、不可变基础设施和声明式 API
这些技术可以让我们构建高度稳定、可控、可观测的松散耦合应用
但云原生方案的重点并不是应用部署在何处，而是如何构建、部署和管理应用