软件架构概览：从业务到技术
一、业务架构、应用架构、数据架构与基础设施的关系
软件架构常被拆成几层来看，自上而下：业务架构回答「做什么、为谁做、价值链与流程」——领域、用例、组织与协作；应用架构回答「系统怎么划分、模块如何协作」——服务/模块边界、接口、调用关系；数据架构回答「数据如何建模、存储、流动与一致」——模型、存储、管道、一致性；基础设施回答「跑在哪、怎么部署、怎么扩」——计算、网络、存储、可观测与运维。四者不是孤立的：业务驱动应用划分，应用与数据紧密耦合，基础设施支撑应用与数据。设计时要从业务目标往下对齐，避免「技术自嗨、业务脱节」。
二、常见架构风格：单体、分层、微服务、事件驱动
不同风格对应不同的边界划分与协作方式，各有适用场景与代价。单体：一个部署单元、共享进程与库；简单、一致性强，但扩展与变更粒度粗，适合早期或小团队。分层：表现层、业务层、数据层等，层内高内聚、层间单向依赖；清晰易理解，但层过厚或跨层调用会变味。微服务：按业务/能力拆成独立部署的服务，通过 API 或消息协作；可独立扩与发布，但分布式复杂度、一致性与运维成本上升。事件驱动：通过事件/消息解耦生产与消费，异步、易扩展，但最终一致性、顺序与重试要设计好。风格可组合（如微服务内部分层、事件驱动连接微服务）；选型要看团队规模、业务阶段与约束，而非盲目跟风。
单部署单元、共享进程与库；简单、一致性强；扩展与变更粒度粗。适合早期、小团队。
- 先跑通再拆，避免过早拆分
表现 / 业务 / 数据层，层内高内聚、层间单向依赖；清晰易理解。注意层过厚与跨层调用。
- 可与单体或微服务内部分层结合
按业务/能力拆独立服务，API 或消息协作；可独立扩与发布。分布式复杂度与运维成本高。
- 适合团队与域边界清晰、需要独立演进时
事件/消息解耦生产与消费，异步、易扩展。要处理好最终一致性、顺序与重试。
- 常与微服务组合：服务间通过事件通信
三、在软件行业中应用前文通用思维
前文讲的抽象、边界、权衡在软件里都有直接对应。抽象：领域模型、接口与实现分离、分层抽象；保留本质、隐藏细节，便于理解与演进。边界：模块/服务边界、API 契约、数据归属；边界清晰才能独立开发、部署与排错。权衡：一致性与可用性（CAP）、性能与成本、简单与灵活、交付速度与技术债；每个架构决策都是在约束下的取舍。把「抽象层次选对、边界划清、权衡写进 ADR」当成习惯，软件架构就不会沦为「画图好看、落地乱套」。
通用思维在软件中的体现
- 抽象： 领域模型、接口与实现分离、分层；保留本质、隐藏细节，便于演进。
- 边界： 模块/服务边界、API 契约、数据归属；清晰边界才能独立开发、部署与排错。
- 权衡： 一致性 vs 可用性（CAP）、性能 vs 成本、简单 vs 灵活、速度 vs 技术债；决策即取舍，写进 ADR。
要点： 从业务到应用、数据、基础设施四层要对齐，业务驱动技术；常见风格有单体、分层、微服务、事件驱动，各有适用场景与代价，可组合；前文抽象、边界、权衡在软件中对应领域模型与分层、模块/服务边界与契约、CAP 与速度与债等取舍。
反例：技术层与业务脱节、盲目上微服务、只画图不写权衡。
某团队业务还没跑顺就拆了一堆微服务，运维与排错成本暴增，交付反而变慢。某系统「应用架构图」画得很漂亮，但模块边界模糊、接口随意演变，协作靠口头约定，上线后故障难定位。还有设计文档只写「我们采用微服务」，不写为什么、不写一致性怎么处理、不写运维与监控策略，评审通过后实现与设计脱节。正确做法：从业务目标往下对齐四层；根据团队规模与业务阶段选风格，单体能撑就先用单体、再按需拆分；把抽象层次、边界与接口、关键权衡写进 ADR 与设计文档。软件架构的目的是在约束下可持续地交付价值，而不是堆砌流行词。
小结： 业务、应用、数据、基础设施四层要自上而下对齐；常见架构风格（单体、分层、微服务、事件驱动）各有适用场景与代价，可组合；前文抽象、边界、权衡在软件中体现为领域与分层、模块/服务边界与契约、CAP 与速度与债等取舍。下一章讲高可用、可扩展与可维护：可用性、扩展性、可维护性的架构化实现与 CAP 的运用。
四、小结
软件架构概览把前文通用思维落到软件行业。从业务到应用、数据、基础设施四层要对齐；单体、分层、微服务、事件驱动等风格要按场景与约束选择与组合；抽象、边界、权衡在软件中具体化为领域与分层、边界与契约、CAP 与速度与债。下一章讲高可用、可扩展与可维护：冗余、故障隔离、熔断、水平扩展、可观测与可部署等非功能需求的架构化实现。