万字长文！多图！结合DDD讲清楚编写技术方案的七大维度( 五 ) _DDD

3.5.3 综合应用上述实例业务和代码并不复杂，其实复杂业务场景也不过是简单场景的叠加、组合和交织，无外乎也是通过纵向做隔离、横向做编排寻求答案。

文章插图

纵向维度抽象出能力池这个概念，能力池中包含许多能力，不同的能力按照不同业务维度聚合，例如优惠能力池，物流能力池，退款能力池。我们可以看到两种程度的隔离性，能力池之间相互隔离，能力之间也相互隔离。
横向维度将能力从能力池选出来，按照业务需求串联在一起，形成不同业务流程。因为能力可以任意组合，所以体现了很强的灵活性。除此之外，不同能力既可以串行执行，如果不同能力之间没有依赖关系，也可以如同流程Y一样并行执行，提升执行效率。
此时我们回到本文足球运动员管理系统，如果采用纵向和横向思维分析3.3.1足球先生选拔业务场景可以得到下图：

文章插图

纵向隔离出进攻能力池，防守能力池，门将能力池，横向编排出前场、中场、后场、门将四个流程，在不同流程中可以任意从能力池中选择能力进行组合，而不是编写冗长的判断逻辑，显著提升了代码可扩展性。

3.6 分层看架构系统架构总体而言分为两个层次，第一种层次是指本项目在整个公司位于哪一层次。持久层、缓存层、中间件、业务中台、服务层、网关层、客户端和代理层是常见的分层架构，大多数情况下业务需求最终会体现在服务层，不同的业务领域对应不同的微服务。

文章插图

第二种层次是指本项目内部代码的组织方式，一般可以分为接口层，访问层，业务层，领域层，外部访问层和基础层。
(1) api接口层：提供面向外部接口声明和DTO
(2) controller访问层：提供HTTP访问入口
(3) service业务层：提供BO对象，领域层和业务层都包含业务，但是用途不同。业务层可以组合不同领域业务，并且可以增加流控、监控、日志、权限控制切面，相较于领域层更为丰富
(4) domain领域层：提供DMO、VO、事件、DO和数据访问，核心是根据领域进行分包，领域内高内聚，领域间低耦合
(5) dependency外部访问层：在这个模块中调用外部RPC服务，解析返回码和返回数据
(6) infrastructure基础层：包含通用基础功能，例如基础工具，缓存工具，打印日志，消息发送

文章插图

本文仅展开领域层进行分析。领域层核心是按照领域进行分包，并且提供DMO、VO、事件、DO和数据访问，领域内高内聚，领域间低耦合。

文章插图

3.7 接口看对接一个接口代码编写完成后，那么这个接口如何调用，输入和输出参数是什么，这些问题需要在接口文档中得到回答。
接口文档生成有两种方式，第一种方式是自动生成，例如使用Swagger框架，第二种方式是手工生成。自动生成的优点是代码即文档，还具有调试功能，在公司内部进行联调时非常方便。但是如果接口是提供给外部第三方使用，那么还是需要手工编写接口文档。一个接口核心描述无外乎接口名称、接口说明、输入参数、输出参数，其它信息根据需要再增加。

文章插图

4 文章总结本文通过一个业务实例介绍了技术方案的七大维度：四色分领域、用例看功能、流程三剑客、领域与数据、纵横做设计、分层看架构、接口看对接。每个维度描述系统的一个侧面，组合在一起最终描绘出整个系统。
在实际开发中如果需求不复杂，那么也不是七个维度都要体现，而是根据实际情况取舍，能够把方案说清楚即可，希望本文对大家有所帮助。