端口和适配器架构——DDD好帮手( 三 ) _适配器

文章插图
近两年开始流行的契约测试也可以认为是Driving Adapter测试的扩展

业务逻辑测试，通过Mock出口端口，同样可以方便地构造测试数据，而且这里应该都是Plain Object，测试可以完全在内存中运行，速度是最快的

文章插图
传统的单元测试

Driven Adapter测试，目标是验证按预期的方式操作了外部工具、下游服务、数据库。传统上，涉及这些外部依赖的测试编写难度大，运行速度慢，但如果出口端口和Driven Adapter设计得当，它们就不涉及业务逻辑，从而需要测试用例会大大减少，通过引入内存数据库、Stub Server等技术，其测试场景的构建难度会改善不少，整体执行时间也会相应减少

文章插图
单一职责的Driven Adapter也降低了测试难度，不过测试速度仍然相对较慢
需要注意的是以上测试都是在技术上检测组件是否符合预期，可以考虑适当加入E2E Test来验证这些组件集成起来可用，业务上符合预期，一般覆盖关键功能的Happy Path场景即可。
促进增量开发
端口和适配器架构可能还能给与我们一些灵感，实施增量开发，不妨看一下这个用户故事分解的例子：
由于旅行社代售的邮轮都来自于Excel表格，只要确定了表格字段含义，我们就可以开始集成，我们选择这张卡来搭建脚手架：

文章插图
如果业务优先级允许，选择技术实现最简单的卡搭建脚手架
接下来在InMemoryCruiseSearch中实现筛选：

文章插图
【端口和适配器架构——DDD好帮手】实现筛选功能
引入LegacyBookingCruiseSource和CompositeCruiseSource

文章插图
扩展数据源，另外还需要扩展Cruise销售渠道的筛选条件实现
最后，可以引入一张技术卡：

文章插图
加入CachingCruiseSource，提升Cruise读取速度
到这里，我们不妨小结一下：

文章插图
端口和适配器架构的组成元素及它的好处
与领域驱动设计的协同增效由于概念简单、易于掌握，端口和适配器架构很适合作为DDD的入门辅导工具，而领域驱动设计的诸多方法也能够补充端口和适配器架构的空白，形成合力。

文章插图
端口和适配器架构与领域驱动设计的协同增效
校验“通用语言”
通用语言是领域驱动设计的核心精髓，它建议各方（无论是领域专家和还是开发人员）对于同一件事都使用相同的词汇。这可以防止各方在沟通领域问题、制定解决方案时不会由于不同的专业背景产生误解，最终促进了识别正确的问题，采用正确的解决方案。甚至有激进的观点认为“领域模型就是通用语言本身” 。
端口和适配器虽然不能直接帮助我们找到领域模型或通用语言，但它有助于我们从通用语言中快速剔除技术概念：凡是用于实现适配器的技术细节都应该被排除。让我们回到DDD Cruise的例子：

文章插图
对话片段，注意绿色字体都和Driven Adapter有关，它们应该被通用语言排除
作为“DDD战术设计”的脚手架
领域驱动设计于2004年横空出世，一年后端口和适配器被提出，在战术设计层面，我们可以发现诸多相似点，互为呼应。以架构为例，DDD原著中提出的架构很有意思：乍看之下，以为是传统的分层架构，但却强调了Infrastructure对各层的实现。