请求/响应模型：为何用例输入输出必须独立于框架与业务实体

[[用例只在自动化系统内才有意义控制业务实体交互是DIP的又一应用]]接收输入、产生输出，但设计良好的架构里，用例对象不该知道数据最终以何种方式展现给用户或其他组件——用例类的代码里不该出现HTML或SQL这类展现层细节。因此用例接收的输入应该是一个简单的请求性数据结构，返回的输出应该是一个简单的响应性数据结构，这些数据结构不该派生自HttpRequest、HttpResponse这类标准框架接口，也不该了解任何用户界面细节——这种独立性至关重要：如果请求/响应模型不是完全独立的，用到它们的用例就会连带背上模型本身带来的一整套依赖。一个容易踩的坑是想在这些数据结构里直接引用业务实体对象——毕竟业务实体和请求/响应模型之间确实有不少重叠数据，但千万不要这样做：业务实体和请求/响应模型存在的意义完全不同，随着时间推移，两者会以不同的原因、不同的速率变化，把它们以任何方式捆绑在一起，都是在违反[[CCP共同闭包原则是SRP在组件层面的再度阐述]]和[[SRP的真正含义是只对一类行为者负责而非只做一件事]]——这种违反的直接后果，往往是代码里冒出大量分支判断语句和用来做数据转换的中间数据结构，把本该干净的用例逻辑搅浑。