共计 3954 个字符，预计需要花费 10 分钟才能阅读完成。
前言：
谈到“架构”这两个字，会有好多的名词闪现，比如: 分层架构、事件驱动架构、DDD、CQRS 等。亦或者一堆的软件设计原则，如：KISS 原则（Keep it Simple and Stupid）、SOLID 原则 (单一责任原则、开放封闭原则、里氏替换原则、接口分离原则、依赖导致原则) 等。甚至如状态图、用例图、时序图、活动图等 UML 建模，GOF 设计模式等。本文不会讨论这些架构概念，而是从闲鱼详情页这个业务场景出发，分析出当前的业务问题和痛点，然后通过一步步的架构推导设计，解决这些痛点。随着业务的发展，相信这些问题大家都会遇到。而解决问题的过程，或多或少的会用到上面的设计原则。
一：老的业务架构 – MVC 架构
很多同学开始写业务的时候，基本都会先建表，然后生成 CURD，最后再堆业务逻辑，从 DAO->Manager->Service->Controller 一路写到底。在业务小的时候，这种架构非常的简单实用，可以快速的开发上线。但随着业务发展，人员不断增加，老的架构难以支撑业务的发展，稳定性和效率受到极大挑战。蛮荒时代已过，精耕细作的时代到来，急需一种更合适的架构来支撑业务的发展。以闲鱼的详情页举例，在业务初期，详情的样式只有普通的开价宝贝一种，但随着业务的发展，演变出拍卖、免费送、租房、玩家等细分领域的商品详情页（我们将细分领域的业务命名为“垂直业务”）。
此时，还不断的在老的业务逻辑里添加新的业务逻辑，导致所有的详情业务逻辑堆在一起。于是乎，会出现下面的场景：1）今天 A 详情业务线的同学，加了段逻辑，挂了，影响了所有业务线的同学；2）B 详情业务线的同学想做单独的监控、缓存、降级等，做不到啊，大家的逻辑在一起，改造成本太高；3）C 详情业务线的同学本想只关注 C 详情业务逻辑，发现所有业务都在一起，不得不将所有业务都理清楚一遍；4）D 详情业务线的同学发现前面的业务逻辑太复杂，为了将影响面减少到最小，找了一个认为最安全的地方，加了一段 D 详情业务的特殊处理。
有人可能会问，堆逻辑正常的啊，加几行代码，业务就上线了，互联网提倡的敏捷开发，当然是怎么快怎么来。但敏捷开发 != 提需求 + 编码 + 发布，加几行代码交付业务上线，可能会带来眼前的收益，但一直这么下去，代码会越来越臃肿，没有设计和文档沉淀的系统，难以维护，出故障只是时间问题。
二：新的业务架构 – 业务隔离 + 领域建模
吉德林法则讲：把难题清清楚楚地写出来，便已经解决了一半。老的架构的问题，归纳起来讲：
1. 业务没有做隔离，所有的垂直业务逻辑都堆在一起，互相影响。
2. 详情页业务足够的复杂，却没有统一的模型，形成统一的认知。
因此，架构的设计方案就着重解决这两个问题。
2.1 业务隔离架构推导与设计
一个业务，有多种形态的实现，很容易对应到设计模式里的策略模式。最粗暴的方式，每个垂直业务都自己实现详情页。
这种方式，业务虽然隔离了，但维护成本极高，添加一个通用的功能，所有业务都需要添加一遍。因此需要将共性内容（不变的部分）抽象出来，将变化的部分由各个垂直业务去实现。
这种方式，解决了业务的隔离，共性的内容统一维护，变化的部分由各个垂直业务独立维护。但此时，所有的业务团队还是在一个应用工程里写业务代码，会出现如下场景：
1)开发阶段，各业务线都在这个应用里拉取一个分支进行开发，集成部署时，代码冲突难以避免。
2)A 业务线添加了一段自己业务线的逻辑，部署失败了，导致其它业务线也无法使用。
3)N 业务线不在自己的团队内，属于外部合作团队，如何添加该业务线的逻辑。
这些场景存在的原因在于，业务代码虽然隔离了，但人员的开发过程并没有隔离。有如下 3 中方法可供选择:
a. 将共性的内容打成二方依赖包，每个垂直业务依赖这个二方包，进行独立应用开发。
这种二方依赖的方法最常用，但在二方服务里添加一个通用功能的时候，要告知所有业务方都升级二方包，还要发版，升级的成本高。
b. 垂直业务独立应用开发，然后将代码打成 jar 包，再集成到共性业务应用里，一起部署。
该方法依赖关系跟方法 a 相反，但部署方式不够灵活。如果要实现垂直业务的独立部署，改造成本太高，需要做类隔离，budle 隔离等。
综合 a 和 b 的优点，将共性的业务独立部署，垂直业务既可以独立部署，也可以写在共性内容应用里。当调用某个垂直业务实现时，可以自动路由到具体的垂直业务实现（这个垂直业务实现可以是一个本地调用，也可以是一个远程调用）。这样，垂直业务的开发人员就可以在自己的应用中开发、部署、运维，解决开发人员的隔离问题。
至此，业务的隔离，开发人员的隔离问题都已解决。但该架构方案显然不只有详情这一个场景可用，其他类似的业务场景也有相似的问题。因此，架构的代码不能与业务的代码耦合在一起，需要将架构的代码独立出来，形成通用的技术工具，以应用于所有类似的业务，业务开发应该只关心业务的事情。我们特地为此开发了一个多实现“业务隔离”路由工具，最终的隔离架构设计图如下：
2.2. 领域模型在详情页的使用
隔离的问题解决了，再来谈谈详情页的领域建模。
为何需要领域建模？好多 java 开发的同学，大都会遇到这样的问题：1）一门 OO(面向对象)的语言，写出来的代码都没有 OO 的感觉，到像是过程式的代码，面向对象的思想基本没有使用到。2）虽然代码满足了业务需求，但从代码中，完全看不到业务领域的影子，业务领域和代码是脱节的。3）随着业务的越来越复杂，里面的依赖关系梳理起来非常困难，业务模块没有边界可言。
为了不给后人挖坑，为了解决详情页复杂的逻辑，为了让代码更有范，为了让接手详情的同学都有统一的业务领域认知，因此决定对详情领域进行领域建模。
Eric Evans 的那本《领域驱动设计——软件核心复杂性应对之道》经典书籍大行其道十几年，网上关于领域建模的文章也是浩如烟海，自顶向下、自底向上、四色原型建模、问题空间领域模型抽象方法论也非常的多。但这些文章和书籍，要么谈论理论概念，要么谈论建模方式，对初学者来说，看完之后，还是写不出相应的代码。
所以本文不在重复的去讲领域建模的概念，直接通过闲鱼详情页这个业务场景，讲述建模的步骤、DDD 的代码展示，给读者一个更直观的参考。
2.2.1 详情页领域建模
闲鱼详情页是一个纯展示的页面，用一句话可以概括为，“详情页是包括：商品、卖家、买家、鱼塘、认证、互动等内容的信息聚合展示页”。这里我们使用四色原型建模法进行建模。上面的这句话最骨干的内容为：详情页是一个“信息聚合展示页”（瞬间事件）。
骨干内容定义好后，为了更好的描述详情页是什么，需要补充一些实体对象，详情页主要包含商品、卖家、买家、鱼塘这些实体（人 - 物 - 地点）。
在此基础上，进一步的进行抽象，用户实体中，有卖家、买家这个角色存在；鱼塘实体中，又有塘主、塘民角色存在（塘主也是塘民，所以塘主应该继承自塘民）。加入角色后的模型如图 11 所示：
最后，再把一些描述信息放进去
有了模型的设计，再转为类图设计。根据模型的抽象，详情页是信息展示的聚合，因此它是个聚合根，包含了商品、卖家、买家、鱼塘这些实体信息。商品信息描述里，又有视频、图片、文本、互动等信息。视频、图片可以抽象为媒体信息。使用 UML 设计出最终的类图，如图 13 所示
2.2.2 DDD 代码展示
在实现详情页时，依据的是 DDD 中的定义。DDD 中最主要的内容包括：entity、value object、aggregate、repository、factory 和 service（如图 8 所示），以及 Infrastructure, Domain, application 和 User Interface 分层结构，如图 14 所示：
Infrastructure 主要用于持久化数据的读取和写入；Domain 为领域层，提供领域信息，这是业务的核心所在；Application 是很薄的一层，没有业务逻辑，用来协调应用活动；User Interface 负责用户信息展示。将这个分层结构映射到工程结构如图 15 所示。
这里的 Applicaiton 层没有业务逻辑，只作为二方服务对外提供。此外，工程结构中没有写 User Interface 层，因为该应用是以二方服务提供，当然，如果提供 REST 服务，则可以写在这一层。
多数的用户对 MVC 架构比较了解，因此，图 16 对比了 DDD 的分层架构和 MVC 的架构，以做参考。
根据上文的模型抽象，领域对象主要有 ItemEntity, SellerEnity, BuyerEntity, FishPoolEntity，并通过详情页聚合根 DetailAggregate 聚合。
在图 15 应用结构分层中，有 3 种类型的数据对象，DO 对象表示持久化的数据对象，Entity 为领域对象，DTO 为对外的传输对象。
首先通过领域层的 Repository，调用基础设置层的 Dao 读取 DO 结构，再使用 Convertor 转为 Entity 领域对象。
领域 entity 处理各自的领域业务逻辑，然后通过领域层的 DetailService，对聚合根 DetailAggregate 进行整体详情页业务领域处理。最后转为 DTO 传输对象提供对外服务。
三: 总结和思考
本文从详情页业务出发，当业务越来越复杂时，如何做业务的隔离，做开发人员的隔离，以及如何通过领域建模，形成统一认知。给大家提供一个可行的参考。
但没有任何一种架构可以适用于所有的场景，也没有任何一个架构是最优的，所谓架构，都在解决“边界”的问题。因此都需要从实际的业务场景出发，明确出问题的边界在哪里，要达到什么样的目标，再遵循一些基本的原则和方法，基本都能够设计出符合自己业务特性的架构。
接下来将会给大家分享一篇从不同的视角出发，进行的业务架构设计。
本文作者：闲鱼技术 - 绛曲阅读原文
本文为云栖社区原创内容，未经允许不得转载。
