领域驱动模型DDD（一）中，如何实施高效服务策略？

本文共计3896个文字，预计阅读时间需要16分钟。

前言+领域驱动模型设计在业界也喊了几年口号了，但很多实用的程序员来说，纸上谈技远比现世码难得多。个人能力有限，在拜读相关著作时，已尽量忽略书中晦涩难懂的部分。

前言

领域驱动模型设计在业界也喊了几年口号了，但是对于很多“务实”的程序员来说，纸上谈“术”远比敲代码难得太多太多。本人能力有限，在拜读相关作品时既要隐忍书中晦涩难懂的专业名词，又要去迎合西方大牛在撰写的过程中融入的西式故事。我想总会有一部分水平和我类似的码农们，需要一份对系统阐述DDD小白化的文本。因此，本人便自不量力地结合一些简单的项目经验，将领域驱动模型设计思想从理解到落地的实施和总结分享给诸位。当然，如果是某些行业先锋不幸看到本人稚嫩的文字时，就当作是马戏团中的小丑，一笑了之翻页便可。

思维的入门

在学习架构思想的初期，特别时面对架构模型时（例如六边形架构、领域服务拆分），我总会不自然地在对号入座，思考在模型中的这一块放到代码实现上是Controller层还是Dao层，是采用消息中间件还是NoSQL缓存。这种自动联想的“被动技能”在学习微服务设计架构思想的过程中是致命的，过于专注业务的技术实现而脱离架构思想本身的大局观，就容易陷入用“具体”无法概括“抽象”的处境。

对此，让我们先忘了平日在开发中使用的各种被分类到细致入微的技术，带着一种阅读“无用”文学而非可以模仿实操的工具书的心态一起来对领域驱动设计做一个基础性的理解。

1 常用的服务拆分方法 1.1 根据业务能力进行服务拆分

创建微服务架构的策略之一就是采用业务能力进行服务拆分，这也是目前市面上大部分产品设计初期采用的方式。主要原因是这种方法对于架构师来说是比较容易实施的，就好像在做一个分类游戏，关于用户的注册登录以及信息管理可以划分为一个业务，关于文章的发布下架以及内容更迭可以划分为一个业务。