建议把论文写成一个“核心业务系统从传统三层架构改造为六边形架构”的项目故事。可以设定项目为订单交易、仓储履约、医保结算、供应链采购或企业审批平台。原系统中 Controller、Service、DAO、第三方接口调用混在一起，业务规则散落在接口适配代码中，一旦要接入新的渠道、支付网关、消息队列或数据库，改动会波及核心逻辑，单元测试也很难脱离外部依赖。你作为系统架构师，主导按领域模型重构，将业务核心从框架和基础设施中剥离出来。

展开角度可以按“为什么拆、拆成什么、怎么落地、效果如何”组织。第一部分写问题：外部渠道多、接口协议变化快、数据库或中间件替换困难、核心业务规则难测试。第二部分写六边形架构的结构：领域核心放在中心，包含聚合、实体、值对象、领域服务和领域事件；入站端口定义外部调用核心业务的用例接口，如创建订单、确认库存、发起结算；出站端口定义核心业务访问外部资源的抽象，如订单仓储、支付网关、消息发布、风控查询；适配器负责把 HTTP、RPC、MQ、数据库、缓存、第三方 API 等技术细节转换为端口调用。第三部分写依赖方向：外部依赖内部，核心业务只依赖端口抽象，不直接依赖 Spring MVC、MyBatis、Redis 或某个支付 SDK。第四部分写测试：用内存仓储、Mock 支付、契约测试和领域服务单元测试验证业务规则。

专业技术可以写 DDD、聚合根、值对象、领域服务、领域事件、入站端口、出站端口、适配器、依赖倒置、反腐层、仓储模式、DTO/Assembler 转换、契约测试、Mock、Test Double、事务边界和事件最终一致性。适配场景包括：一个订单系统同时支持 App、开放平台、客服后台和批量导入；一个支付系统需要切换微信、支付宝、银联等通道；一个库存系统需要从 MySQL 迁移到分库分表或接入消息队列；一个政企业务系统需要同时对接多个外部审批平台。

论文里要写出落地阻力。比如团队初期把六边形架构误解为多包分层，端口粒度过细导致类爆炸，适配器里仍然夹带业务判断，或者跨聚合事务改造后出现一致性争议。解决方法可以写：先选高变化、高外部依赖的模块试点；以用例划分入站端口，以业务能力划分出站端口；通过架构守护测试或代码扫描禁止领域层反向依赖基础设施；对跨服务流程采用领域事件、消息幂等和补偿机制。指标可以写接口切换周期缩短、核心规则单元测试覆盖率提升、第三方通道替换只改适配器、回归范围减少等。