有关端口-适配器模型的一些总结

        在鲍勃大叔的《架构整洁之道》一书中的拾遗篇，西蒙布朗阐述了代码组织结构横切还是竖切的问题。按我理解，他结合着鲍勃大叔对于架构的通篇阐述后，指出了单纯的按照传统的MVC（横切）和SOA、微服务（竖切）等各自弊端，提出了自己关于端口-适配器模型的切分方式。这是一种充分考虑语言封装特性，利用访问权限关键字和包的概念进行代码组织的方式，兼顾了前两者的优点。既解决了当业务量扩大后MVC无业务意义粗粒度的分层不满足需求的问题，又解决了服务间跨包调用依赖混乱、跃层访问的问题，颇具中庸思想。

       按照西蒙的结构模型，是将一组服务分为领域（Domain）组件和外围的基础设施（Infrastructure）组件，用一组同心圆表示一组服务。我将其思想，按照我的理解重新结构图示如下：由于二即是多，本图示用两组服务（垂直切分）来代表一个完整工程。可以看出，每一组服务在上下分层（即横向切分）仍然是MVC结构，只是MVC退化到每一个用例服务的内部了。而每一组服务分别对外提供业务接口IBiz和持久层接口IDao，核心的实现CoreBiz是私有化封装在组件内部的。再回到横向上看，两个灰色背景，就可以是两个大包结构，一个包用于盛装外围基础设施（Infrastructure），例如图示中的控制器层，另一个包就盛装各个服务的领域组件（Domain）。当然，跨包调用（这里指各垂直服务之间的调用）总是难以避免的，因为服务边界和架构边界不是一件很容易划清界限的事情，尤其在设计之初。还好，我们可以随着演进，将公用的数据模型（或实体）、公用的业务组件抽离出来被其他组件去依赖。而在横向层之间的依赖上，VO、BO、PO就需要在数据流向上进行适配了，或许需要提取出一个泛型模板或者通用的ITransformVoToPo接口了。这可能也是为什么该架构叫做端口-适配器模型的原因。相比将所有层的数据模型、实体类作为统一使用的模型并一股脑的堆在entities包里造成依赖混乱、加之ORM框架注解造成的类污染、打包部署等问题，尽管分层数据模型的适配需要麻烦些，带来的好处是依赖关系非常清晰易于管理。所以，关于是否有必要单独抽象出实体层，这不是关系到架构的核心问题，属于实现细节问题。比如编程范式采用函数式风格、语言采用弱类型动态语言、持久化选用非ORM框架等，完全可以不用OOP制造数据模型，而使用基础数据结构来实现。这是一个见仁见智的问题，也要取决于项目实际情况、开发规范等要求了。