领域驱动在代码层面的落地感悟

最新推荐文章于 2024-01-22 09:13:39 发布

骑着猪追马的程序媛

最新推荐文章于 2024-01-22 09:13:39 发布

阅读量180

点赞数

文章标签：微服务 big data microservices

本文链接：https://blog.csdn.net/shyyyyyyyyyyy/article/details/122013684

版权

本文分享了在小米有品会员系统的业务场景下，如何采用领域驱动设计（DDD）来应对业务复杂性和扩展需求。通过战略设计和战术设计，结合事件风暴和四色建模方法，实现微服务架构下的DDD落地。文章强调了DDD的核心概念，并提供了代码层面的实例，展示了DDD在业务逻辑、限界上下文和分层架构中的应用。

摘要由CSDN通过智能技术生成

笔者杨涛12年互联网从业经验，8年技术管理经验。先后从事搜索、社交、在线教育、电商等行业相关工作，对高并发和复杂业务场景解决方案均有较深入的经验积累。

背景

小米有品随业务发展，推出了会员系统。包含满5单返会费，开卡礼包、每月优惠券、会员价、优先购等等权益和福利等业务场景。在初期的需求调研过程中，会员系统业务复杂性已经得以显现。按计划，未来业务上还会有横向和纵向上的扩展（如横向上权益增加、多会员身份，纵向上的等级制度等等）。

业务特点与挑战

影响范围广，会员权益几乎覆盖所有主要业务场景，例如产品站、购物车、结算页、会场页和会员频道等场景
逻辑复杂，权益类型多，状态多（例如有15个左右的退款状态，未来还会增加）
关联服务较多，如会员卡购买与购物车、订单、履约等系统相关，权益与卡券、优惠、商城相关，省钱计算器与订单、卡券相关
需要为业务扩展和升级留下充足空间，代码上模块间要尽可能的减少耦合（数据库表设计上，我们本次几个主要表都放弃加唯一键约束(非主键)，使用程序来控制唯一性更有利于横向扩展）

为什么选择领域驱动

会员中心定位是中台服务，团队之前也对领域驱动有了一些积累，加之要准确快速实现如此复杂的业务，还要满足后续紧接着的各种扩展需求，领域驱动此时成了最佳选择。
领域驱动设计简称DDD（Domain-Driven Design），是一种开发思想体系，旨在设计和管理复杂问题域编写的软件，由Eric Evans于2003年提出。由于种种原因，它在国内的应用并不广泛，不过其中的一些概念早已经出现在我们的日常工作中了，例如我们在代码中看到的XxxEntity，XxxRepository ，XxxService，XxxFactory。
它本身理论的复杂度高，学习成本高，在国内一直没有得到广泛的应用，直到后来微服务和中台的出现。领域驱动中领域和限界上下文等概念，如天然为服务拆分和治理所准备。不过毕竟是18年前提出的理念，当初的DDD并不能完全适用现在，我们需要搭配事件风暴、四色建模等分析和建模方法。
微服务经过这么多年发展，相关架构理论越来越成熟，加上事件风暴、敏捷迭代等工程方法得到广泛运用，再去看领域驱动已经不再那么难了，甚至可以根据自己项目特色，设计合适自己的落地方案。

企业应用开发范式比较：数据驱动、特性驱动与领域驱动：