wp与ci4紧耦合导致系统僵化，重构需重建职责边界：controller仅处理请求与响应，service承载业务逻辑，repository专注数据存取，view彻底哑化，并通过openapi契约、hmvc模块化及渐进式迁移实现解耦。
WP耦合架构（指WPF中常见的视图与逻辑紧耦合写法）难以维护，根本症结在于UI层直接掺杂业务判断、数据转换、状态流转甚至服务调用。而CI4（CodeIgniter 4）虽标称MVC，其默认分层仍偏扁平——Model常沦为数据库操作封装，Controller易膨胀为“万能调度员”，View可能嵌入大量PHP逻辑。二者叠加，会加速系统僵化。重构不是简单搬动文件，而是重建职责契约和调用边界。
明确分层意图：从“物理分目录”到“逻辑责任域”
CI4默认的app/Controllers、app/Models、app/Views只是文件夹，不等于分层。重构第一步是定义每层的不可逾越边界：
- Controller只做三件事：接收请求参数、校验格式合法性、调用Service并返回响应（JSON或View）。禁止查库、拼SQL、处理金额精度、发消息。
-
Service层承载真实业务：一个Service类对应一个业务能力（如
OrderFulfillmentService），它协调多个Repository、调用领域规则、触发领域事件。它不关心HTTP、Session或模板。 -
Repository专注数据存取契约：每个Repository只面向一个聚合根（如
OrderRepository），提供find()、save()、delete()等方法，内部可切换Eloquent、Query Builder或缓存实现，上层无感知。 -
View彻底哑化：仅使用传递进来的DTO或ViewModel对象，禁止
if($user->role === 'admin')这类业务判断；复杂展示逻辑抽成独立Presenter或View Helper。
切断WP与CI4的隐式依赖链
若项目混合WPF客户端与CI4后端API，常见陷阱是WPF直接消费CI4的View渲染结果（如抓取HTML片段），或在WPF里复用CI4的Model类。这会导致：
- WPF更新需同步改CI4模板，违反关注点分离；
- CI4 Model加了验证规则，WPF绑定时抛异常却无法捕获上下文；
- 双方共享DTO导致编译耦合，一方改字段名另一方必崩。
解法是强制引入**契约先行**：
- 用OpenAPI 3.0定义API接口（路径、请求体结构、响应体结构、错误码），WPF与CI4均据此生成客户端和服务端骨架；
- CI4的Service返回严格类型化的DTO（非Eloquent模型），DTO类放在
app/Dto下，与Model物理隔离； - WPF通过强类型HttpClient调用，不解析HTML、不依赖CI4的View路径或CSRF机制。
用HMVC思想补足CI4的模块粒度缺陷
CI4原生不支持模块化嵌套，但大型项目需要按业务域（如“营销中心”、“售后工单”）独立演进。直接在app/下堆Controller会失控。此时应借力HMVC理念，而非强套HMVC库：
- 按业务域建一级目录：
app/Modules/Marketing/、app/Modules/AfterSales/； - 每个Module内含自己的
Controllers、Services、Repositories、Dto，但禁止跨Module直接new Class或use全限定名； - 跨域协作统一走
Service Locator或依赖注入容器（CI4已支持）：$service = service('marketing::coupon_validator');； - 路由配置按Module分组，避免
/api/coupons和/api/refunds路由散落在不同文件里。
渐进式重构的落地节奏
不追求一次性重写。优先从高频变更、高风险模块切入（如订单创建流程）：
- 第一步：将原Controller中所有数据库操作剪切到新Repository，原Model降级为纯数据载体（DTO）；
- 第二步：把校验、计算、第三方调用逻辑移入新Service，Controller只剩
$service->createOrder($dto)； - 第三步：为该Service补全单元测试（Mock Repository），验证主干路径与异常分支；
- 第四步：WPF侧同步替换调用方式，从解析HTML改为消费JSON API，并用Contract测试验证字段一致性。
每次迭代都让一块代码变“软”——改需求时只动Service，加字段时只改DTO和API文档，前端换UI不碰后端逻辑。
