先自顶向下设计，再自底向上实践
设计系统的时候，也会有一些偏好：
- 不多也不少：即不做多余的设计，也不缺少关键部分的设计。
- 演进式：不断让架构适应当前的环境。
- 持续性：长期的架构改进，比什么都重要。
演进式+持续性
C4模型
C4 代表上下文（Context）、容器（Container）、组件（Component）和代码（Code）——一系列分层的图表，可以用这些图表来描述不同缩放级别的软件架构，每种图表都适用于不同的受众。—— Simon Brown 《程序员必读之软件架构》
高度自动化的工作流以及可视化
设计架构的适应度部分，
一个合理的 README 应该包含：
- 项目简介：用一两句话简单描述该项目所实现的业务功能；
- 技术选型：列出项目的技术栈，包括语言、框架和中间件等；
- 本地构建：列出本地开发过程中所用到的工具命令；
- 领域模型：核心的领域概念，比如对于示例电商系统来说有Order、Product等；
- 测试策略：自动化测试如何分类，哪些必须写测试，哪些没有必要写测试；
- 技术架构：技术架构图；
- 部署架构：部署架构图；
- 外部依赖：项目运行时所依赖的外部集成方，比如订单系统会依赖于会员系统；
- 环境信息：各个环境的访问方式，数据库连接等；
- 编码实践：统一的编码实践，比如异常处理原则、分页封装等；
- FAQ：开发过程中常见问题的解答。
边界限定的系统架构
过去，我们采用模块化来划定包之间依赖关系；现在采用的是微服务化取代了部分内部包依赖。即以 HTTP 请求代替来函数调用。
所以，我们将巨型单体应用（陷阱 11 ）视为一种毒瘤，顺带强调一下巨型！巨型！巨型！
适配层，而非被接口适配
事件风暴（Event Stroming）是一项团队活动，旨在通过领域事件识别出聚合根，进而划分微服务的限界上下文。
通过领域事件来划分边界
应用微化架构
实现上它是一种：
- 构建时拆分架构。
- 代码删除架构。笑，以删代码的方式，来形成每个前端应用。
- 微前端准备式架构。即，随时可以拆分为多个前端应用。