【Day 2】层次架构在企业ERP中的设计一、题目还原题目场景某大型制造企业计划升级其ERP系统该系统覆盖采购管理、生产计划、库存管理、财务核算和人力资源五大核心模块。现有系统采用传统单体二层架构客户端直接访问数据库随着业务扩张已出现以下问题①代码耦合严重一次修改影响多个模块②业务流程变更频繁需求响应周期长达3个月③安全性差数据库连接直接暴露给客户端④无法支撑多工厂分布式部署需求。系统架构师提出了基于层次架构风格的重构方案将系统划分为表现层、业务逻辑层、数据访问层和基础设施层。【问题1】6分请分别阐述严格分层与松散分层的区别并结合该ERP系统的业务特点说明应选择哪种分层策略。【问题2】9分针对上述分层架构请设计层间通信策略包括各层之间的调用方式、数据传输对象DTO的设计原则、以及层间解耦手段。【问题3】5分在该ERP系统采用层次架构后请分析其对质量属性可修改性和性能的影响指出一个可能的权衡点。【问题4】5分如果将该ERP系统的部分模块如采购审批流程改用事件驱动架构集成到现有分层架构中请分析这种混合架构的优缺点。二、考点分析核心考点层次架构风格——分层策略对比严格分层 vs 松散分层与层间通信设计。答题模板模板一架构风格选择题理由阐述 模板四系统设计/方案评价本题对应的答题框架Q1概念辨析型——先给出两种策略的定义再结合案例选型理由Q2方案设计型——分层定通信方式 DTO设计 解耦手段至少3条Q3质量属性分析型——两个属性的影响分析 权衡点识别Q4混合风格分析型——事件驱动的适用场景 优缺点分析三、标准答案采分点格式【问题1】严格分层 vs 松散分层6分维度严格分层Strict Layering松散分层Relaxed Layering定义每一层只能调用其直接相邻下层的接口不能跨层调用允许上层访问非相邻下层的接口跨层调用受控层间可见性仅可见相邻下层可可见特定非相邻下层耦合度耦合度最低修改影响局部化耦合度中等存在跨层依赖风险性能开销较高层层透传增加调用链较低可绕开中间层直接访问维护性高修改某层接口不影响上层以外中跨层调用可能产生连锁影响选型决策建议采用严格分层为主、有限放宽的混合策略。理由结合ERP业务①采购管理模块业务逻辑复杂变更频繁→ 严格分层确保可修改性优先②报表查询场景高频读取纯展示数据→ 有限放宽允许表现层绕过业务层直接调用数据访问层的只读查询接口降低响应延迟③财务核算模块安全性要求极高有合规审计要求→ 必须严格分层所有请求经过完整的业务校验和数据权限控制④多工厂部署需求→ 严格分层便于将各层独立部署到不同服务器实现分布式扩展。【问题2】层间通信策略设计9分1调用方式设计4分调用方向通信方式技术选型说明表现层→业务层同步RPC调用Spring Cloud OpenFeign / Dubbo请求-响应模式事务一致性要求高的场景业务层→数据访问层接口调用SPIMyBatis Mapper 接口 / JPA Repository通过IoC注入接口实现业务层依赖抽象而非实现业务层→基础设施层异步消息RabbitMQ / RocketMQ日志记录、审计、通知等非核心链路跨服务通信事件驱动可选Spring Cloud Stream Kafka模块间解耦如采购审批完成后触发库存更新2DTO设计原则3分原则说明ERP示例每层独立DTO各层使用独立的数据传输对象不共享DO表现层用OrderVO、业务层用OrderDTO、数据层用OrderPODTO仅含所需字段不给上层暴露不需要的数据业务层返回给表现层的DTO不包含数据库自增ID、内部状态码使用转换器Assembler层间通过Assembler进行DO↔DTO转换OrderAssembler.toDTO(orderPO)封装转换逻辑3层间解耦手段2分①依赖倒置原则DIP上层定义接口下层实现接口依赖关系指向抽象而非具体实现。例如业务层定义IOrderRepository接口数据访问层提供MyBatisOrderRepository实现。②控制反转IoC通过Spring容器管理依赖注入运行时装配具体实现。切换数据库访问框架时只需替换Bean实现业务层代码无需修改。③防腐层ACL在层边界处放置适配器将下层变化隔离在上层之外。例如当底层从MySQL迁移到TiDB时数据访问层接口不变只需替换内部实现。【问题3】质量属性分析5分对可修改性的影响正向2分关注点分离每层职责明确修改财务核算的规则只需修改业务逻辑层不影响表现层和数据层局部化修改采购模块的审批流程变更只需修改采购业务服务不会波及库存管理接口稳定定义清晰的层间契约新增业务功能只需新增接口实现遵循开闭原则对性能的影响负向2分调用链加长一个简单查询需要经过表现层→业务层→数据访问层→数据库经过多层对象转换和参数校验序列化开销层间DTO转换涉及对象拷贝和序列化/反序列化增加CPU和内存开销网络延迟分布式部署时跨层调用变为远程RPC增加网络RTT权衡点1分可修改性 vs 性能严格分层增强了可修改性模块独立、变更隔离但每一次请求必须经过完整的层次栈增加了调用链长度和对象转换开销。这是一个典型的权衡点——架构师需根据具体场景选择策略对核心交易链路如订单创建采用严格分层保证可维护性对高并发查询场景如库存查询适当放宽分层规则或引入缓存层减少调用次数。【问题4】事件驱动层次结构的混合架构5分优点3分①异步解耦采购审批完成后发布审批通过事件库存模块、财务模块异步订阅处理无需同步等待提升系统吞吐量。②可扩展性强新增审计模块只需订阅相关事件无需修改现有代码符合开闭原则。③削峰填谷审批流程在ERP中通常有业务高峰期如月末集中审批事件队列可缓存洪峰请求避免后端过载。缺点2分①数据一致性降低异步事件可能导致最终一致性问题。例如采购审批通过但库存扣减失败需要引入Saga或补偿事务机制。②调试复杂度增加事件流链路难以追踪需要引入分布式链路追踪如SkyWalking和事件溯源机制。③消息中间件成为新依赖系统可用性依赖于消息中间件的稳定性需部署集群和副本机制保证高可用。四、评分要点题号分值必备采分点答出即可得分加分项Q16分① 说清严格分层的定义只能调用相邻下层【1分】② 说清松散分层的定义允许跨层调用【1分】③ 给出选型结论并会结合ERP业务提出差异化策略【2分】④ 至少给出1个具体模块的分层策略理由【1分】提及财务模块需要严格分层以保证安全审计合规 0.5分Q29分① 设计了至少2种层间通信方式【2分】② 给出了DTO设计原则提到了独立DTO或转换器【2分】③ 给出了至少2种解耦手段【2分】④ 有具体的技术选型如Spring、MyBatis【1分】提到传输对象模式TO、防腐层ACL0.5分提到异步消息同步RPC双通道设计 0.5分Q35分① 正面分析可修改性每层独立修改、接口稳定【1.5分】② 负面分析性能调用链加长、对象转换开销【1.5分】③ 明确指出可修改性 vs 性能是权衡点【1分】提出针对不同场景采用不同分层策略的差异化方案 1分Q45分① 给出混合架构方案描述【1分】② 分析至少2个优点【2分】③ 分析至少2个缺点或应对措施【2分】提到分布式事务Saga0.5分提到事件溯源Event Sourcing0.5分扣分项空谈理论不结合ERP业务场景 → 扣30%混淆严格分层与松散分层的定义说反了→ Q1不得分将层间通信等同于直接方法调用不考虑DTO解耦 → 扣1分未识别权衡点 → 扣1分五、扩展知识点 层次架构 vs 微服务架构补充对照维度层次架构微服务架构部署粒度整体部署一个WAR包独立部署每个服务独立容器通信方式进程内部调用或RPC远程调用HTTP/gRPC/消息队列数据存储共享数据库数据库独立Database per Service适用规模中型企业系统大型互联网系统ERP适用性ERP核心模块财务/生产适合分层架构非核心外围模块消息通知/报表适合微服务 易混淆对照层次架构属于调用返回风格不要与数据流风格管道-过滤器混淆。ERP场景中不同模块可叠加不同风格称为混合架构风格Day 6专题。 质量属性场景6元素与本案例映射场景可修改性场景 刺激源业务分析师 刺激提出新增采购审批加签规则 环境系统运行中生产环境 制品业务逻辑层-审批服务模块 响应修改审批服务代码通过接口扩展实现 响应度量2人天内完成开发不涉及其他层修改 相关答题模板参考模板一架构风格选择→ 用于Q1的选型理由模板四方案评价→ 用于Q4的混合架构分析 公式速查层间调用的延迟公式T_total Σ(T_serialize T_network T_deserialize T_business)严格分层性能劣化比Overhead (n-1) * (DTO拷贝时间 参数校验时间)其中n为层数六、今日金句“层次架构的核心价值在于关注点分离——每一层只解决一个层面的问题层间通过稳定的接口契约通信使系统的可修改性得到质的提升但代价是调用链路延长带来的性能损耗——这就是架构设计中永恒的权衡可修改性与性能的跷跷板。”
