MailProxy案例：逻辑视图与物理视图的迭代设计

运用[[逻辑架构与物理架构的定义与设计任务]]设计一个真实系统时，容易踩的坑是把两个视图当成”两个阶段”来做——先把逻辑架构详尽设计完，再开始物理架构设计。这种瀑布式做法对大型系统有两个明显问题：一是困难，逻辑架构和物理架构是同一系统的不同方面，如果对一个方面毫无所知就深入设计另一个方面，操作起来太盲目；二是不利于提高设计质量，逻辑架构和物理架构交替进行，本身就是一个不断相互验证、促进设计优化的过程。书中用一个邮件代发系统MailProxy（核心功能是对接客户系统、调度Mail Server完成自动代发、反馈发送结果、提供规则设置）的设计过程演示了正确做法：分而治之（逻辑架构做逻辑分解、物理架构做物理分解，各自聚焦、化大问题为子问题）和迭代式设计（不同视图设计交替进行，逻辑职责划分逐步清晰会促进物理分布设计，反之亦然）两个技巧要同时运用，而不是先后使用。具体演进过程是：第一轮逻辑架构设计只能得到粗略的分层（用户交互层/业务逻辑层/数据访问层，外加因为要和多种外部系统交互而新增的”系统交互层”）；转向第一轮物理架构设计，先勾勒出基本的物理分布；再回头做第二轮逻辑架构设计时，物理架构的线索（比如”系统交互层里应该有Mail Server交互模块”）反过来帮助逻辑设计”展开”、”细下去”，最终逻辑模块被归入后台服务器程序、管理员Web应用、代理模块（发布给合作方的API）三个目标程序单元；这个结果又反过来支撑第二轮物理架构设计，让软件单元和硬件机器的映射关系进一步明确，为部署方式提供指导。这个案例最有价值的地方是证明了”死抠某一个视图的未知细节抠不出来”时，转而利用另一个视图当前的已知信息去探索，往往能打破设计僵局——这正是”迭代式设计”作为一种思维习惯而非单纯流程步骤的体现。

结构图：

flowchart TD
    A["理解需求：MailProxy要对接多种外部系统"] --> B["逻辑架构·迭代1\n粗略分层：用户交互层/业务逻辑层/\n数据访问层/系统交互层"]
    B -->|"逻辑分层不够细，转向物理视角"| C["物理架构·迭代1\n勾勒基本物理分布"]
    C -->|"物理线索反哺逻辑设计\n（如'系统交互层需要Mail Server交互模块'）"| D["逻辑架构·迭代2\n细化模块划分，归入3个程序单元：\n后台服务器/管理员Web应用/代理模块"]
    D -->|"逻辑模块和程序单元明确后\n可进一步细化部署映射"| E["物理架构·迭代2\n明确软件单元到硬件机器的映射"]
    E --> F["为安装部署方式提供指导"]