领域驱动设计DDD实战进阶

从部署到实践，即刻拥有你的专属龙虾助手

OpenClaw开发者专区🦞🦞🦞

自行/邀约他人一键搬运博客，享价值百万资源包

腾讯云自媒体同步曝光计划

往期视频·干货材料·成员作品 最新动态

腾讯技术创作特训营知识专栏

新邀入驻腾讯云开发者社区，福利多多！

这个系列我们大概写了八篇文章，将微服务的最重要的内容过了一遍。当然其中有些内容还没有涉及到，比如Docker（不是微服务架构风格中必须的）等，关于Docker我们自己可以在网上找找其他文章。

微服务实战(九)：落地微服务架构到直销系统(回顾总结)

我们先来看看CQRS架构，你对下图的架构还有印象吗？每个组件的功能都还清楚吗？如果有疑问，请查考文章《微服务实战(五)：落地微服务架构到直销系统(构建高性能大并发系统)》。

微服务实战(七)：落地微服务架构到直销系统(实现命令与命令处理器)

在微服务架构风格的系统中，如果单个微服务垮掉或地址不可访问，虽然对系统的影响是有限的，但我们也必须采取一定的手段来保证每个微服务尽量可用；并且在大并发的情况下，虽然可以通过EDA消息队列处理的方式提高吞吐量，但仍然需要WebApi能够更加高效的侦听用户请求，处理消息，即使在某个服务短暂不可用的情况下。本篇文章主要来详细讲一讲要保证微服务的高可用性，可以通过哪些手段来实现。

微服务实战(八)：落地微服务架构到直销系统(服务高可用性)

在CQRS架构中，一个比较重要的内容就是当命令处理器从命令队列中接收到相关的命令数据后，通过调用领域对象逻辑，然后将当前事件的对象数据持久化到事件存储中。主要的用途是能够快速持久化对象此次的状态，另外也可以通过未来最终一致性的需求，通过事件数据将对象还原到一个特定的状态，这个状态通常是通过对象事件的版本来进行还原的。

微服务实战(六)：落地微服务架构到直销系统(事件存储)

在现代系统中，特别是互联网软件，通常会涉及到大量用户的并发访问，我们的系统一定要在架构上支持高性能、大并发的访问。一个高性能的系统通常由很多的方面组成，包括数据库高性能、Web服务器高性能、负载均衡、缓存、软件架构等。我们这篇文章先从软件开发架构的角度作为切入点来介绍如何构建高性能的系统。

微服务实战(五)：落地微服务架构到直销系统(构建高性能大并发系统)

前一篇文章我们已经完成了基于RabbitMq实现的的消息总线，这篇文章就来看看生产者(订单微服务)与消费者(经销商微服务)如何接入消息总线实现消息的发送与消息的接收处理。

微服务实战(四)：落地微服务架构到直销系统(将生产者与消费者接入消息总线)

从前面文章可以看出，消息总线是EDA(事件驱动架构)与微服务架构的核心部件，没有消息总线，就无法很好的实现微服务之间的解耦与通讯。通常我们可以利用现有成熟的消息代理产品或云平台提供的消息服务来构建自己的消息总线；也可以自己完全写一个消息代理产品，然后基于它构建自己的消息总线。通常我们不用重复造轮子（除非公司有特殊的要求，比如一些大型互联网公司考虑到自主可控的白盒子），可以利用比如像RabbitMq这样成熟的消息代理产品作为消息总线的底层支持。

微服务实战(三)：落地微服务架构到直销系统(构建基于RabbitMq的消息总线)

从上一篇文章大家可以看出，实现一个自己的消息总线框架是非常重要的内容，消息总线可以将界限上下文之间进行解耦，也可以为大并发访问提供必要的支持。

微服务实战(二)：落地微服务架构到直销系统(构建消息总线框架接口)

网上有很多关于微服务的文章，从不同的维度对微服务进行了相关的讲述；有些高屋建瓴，有些涉及细节，有些侧重理论，有些侧重代码，都是非常不错的了解微服务的文章。

微服务实战(一)：落地微服务架构到直销系统(什么是微服务)

前面我们花了14篇的文章来给大家介绍经典DDD的概念、架构和实践。这篇文章我们来做一个完整的总结，另外生成一个Api接口文档。
一.DDD解决传统的开发的几大问题：
没有描述需求的设计模型；而是直接通过数据库表的方式体现，也就是需求与设计是脱节的。
编码的架构也没有与设计和需求对应起来。
业务逻辑与技术混在一起；业务逻辑可能直接调用的数据访问，这样把业务逻辑与数据访问的技术混在一起。
开发没有层次感和节奏感；系统没有一个统一的约束，开发人员没有一个统一的节奏，这主要体现在随意的编码。
Bug 定位困难：当系

DDD实战进阶第一波(十五)：开发一般业务的大健康行业直销系统（总结篇）

上一篇文章我们主要讲了订单上下文的领域逻辑，在领域逻辑中完成了订单项的计算逻辑、订单的计算逻辑以及如何生成相应的实体code，这篇文章我们通过
在应用服务中实现一个下单的用例，来将这些领域逻辑以及仓储整合起来，完成一个下单的用例。
先看下单用例主体的代码：
 public class CreateOrderUseCase:BaseAppSrv
    {
        private readonly IOrderRepository iorderrepository;
        private r

DDD实战进阶第一波(十四)：开发一般业务的大健康行业直销系统（订单上下文应用服务用例与接口）

前一篇文章主要讲了订单上下文的POCO模型，其中订单与订单项中有大量的值对象。这篇文章主要讲讲这些值对象以及订单项、订单相关的领域逻辑。
1.ProductSKUs值对象领域逻辑：
ProductSKUs值对象用于订单项实体中，它的信息应该来源于产品上下文的ProductSKU实体。
public partial class ProductSKUs
    {
        public ProductSKUs() { }
        public ProductSKUs CreateProductS

DDD实战进阶第一波(十三)：开发一般业务的大健康行业直销系统（订单上下文领域逻辑）

在本系列前面的文章中，我们主要讨论了产品上下文与经销商上下文相关的实现，大家对DDD的方法与架构已经有了初步的了解。
但是在这两个界限上下文中，业务逻辑很简单，也没有用到更多的值对象的内容。从这篇文章开始，我们来讲讲订单界限上下文实现的内容，
里面的业务逻辑相对复杂一些，而且有大量值对象的引入来进行逻辑的处理。
订单上下文的需求主要是生成相应的订单项，每个订单项中有相关的订单产品和购买数量并生成订单项总额、订单项总PV，同时订单项总额
和订单项总PV会累加到订单总额和订单总PV中，同时会根据订单总额扣减当前

DDD实战进阶第一波(十二)：开发一般业务的大健康行业直销系统（订单上下文POCO模型）

前两篇文章主要实现了经销商代注册的仓储与领域逻辑、经销商登录的仓储与相关逻辑，这篇文章主要讲述经销商代注册的用例与经销商登录的查询功能。
一.经销商代注册用例
在经销商代注册用例中，我们需要传递经销商的基本注册信息，这个信息是做成了DTO对象。
1.经销商注册的DTO对象：
 public class AddDealerDTO
    {
        public string Name { get; set; }
        public string Tel { get; set; }

DDD实战进阶第一波(十一)：开发一般业务的大健康行业直销系统（实现经销商代注册用例与登录令牌分发）

上一篇文章主要讲了经销商注册的仓储和领域逻辑的实现，我们先把应用服务协调完成经销商注册这部分暂停一下，后面文章统一讲。
这篇文章主要讲讲经销商登录的仓储和相关逻辑的实现。
在现代应用程序前后端分离的实现中，通常不是将用户登录的信息存储在服务器端Session，因为会存在服务器Session无法传递的情况，也存在WebApi调用时
无法通过Authorize Attribute判断用户是否已经登录并获取用户身份信息的问题。所以现代应用程序都是由服务器后端返回Token给客户端，客户端将Token存储在客户端

DDD实战进阶第一波(十)：开发一般业务的大健康行业直销系统（实现经销商登录仓储与逻辑）

上篇文章主要讲述了经销商上下文的需求与POCO对象，这篇文章主要讲述该界限上下文的仓储与领域逻辑的实现。
关于界限上下文与EF Core数据访问上下文参考产品上下文相应的实现，这里不再累述。
因为在经销商上下文中有两个聚合，一个是经销商聚合，一个是登录聚合，所以我们需要实现两个仓储接口：
1.经销商仓储接口定义：
 public interface IDealerRepository
    {
        void CreateDealer<T>(T dealer) where T : class,

DDD实战进阶第一波(九)：开发一般业务的大健康行业直销系统（实现经销商上下文仓储与领域逻辑）

从这篇文章开始，我们开始介绍大健康行业直销系统领域层的实现。
先简单讲下业务方面的需求：直销系统会有一个顶级的经销商，经销商的基本信息中包括经销商的名字、联系人(因为在平台购买产品后，会寄送给联系人)、总的电子币（电子币是由经销商支付产生，
购买产品后会扣减电子币）、总的奖金币（系统周期性根据经销商购买的东西来确定奖金币，奖金币可以购买东西，也可以提现）、总PV（经销商购买时，会根据购买产品的PV进行累加）、卡的类型（根据经销商初次的电子币确定卡的类型）、子经销商个数（子经销商的注册由父经销商进行，父经销商

DDD实战进阶第一波(八)：开发一般业务的大健康行业直销系统（实现经销商上下文领域层之POCO模型）

这篇文章其实是大健康行业直销系统的番外篇，主要给大家讲讲如何在领域逻辑中，有效的处理业务逻辑条件判断的最佳实践问题。
大家都知道，聚合根、实体和值对象这些领域对象都自身处理自己的业务逻辑。在业务处理过程中，通常会有一些条件判断，当满足这些条件时，会进行不同的后续处理。在传统的实现中，可以通过If Else条件语句进行判断，但If Else语句在复杂领域中来检查是否满足一些业务条件存在以下的问题：
1.      无法很好的显示表达业务条件本身。
2.      无法对多个条件在不同需要的地方进行灵活的组合。

关于领域对象业务逻辑中条件判断的最佳实践

前一篇文章我们介绍了如何将创建产品的领域逻辑与产品的持久化仓储通过上架产品的用例组织起来，完成了一个功能。在实际的项目中，多种前端的形态比如PC Web、
微信小程序、原生APP等要调用后端的功能，通常要将后端的功能包装成RESTFUL风格，这样前端就可以使用Http Get或Post方式调用后端的功能，所以这篇文章我们先来完成后端
的Asp.net Core WebApi，通过WebApi将上架产品的功能暴露出去。
实现上下产品接口：
[Produces("application/json")]

DDD实战进阶第一波(七)：开发一般业务的大健康行业直销系统（实现产品上下文接口与测试）

前一篇文章我们完成了产品上下文的领域层，我们已经有了关于产品方面的简单领域逻辑，我们接着来实现产品上下文关于仓储持久化与应用层的用例如何来协调
领域逻辑与仓储持久化。
首先大家需要明确的是，产品上下文的领域逻辑是系统的核心，它不应该依赖仓储，而仓储应该要依赖领域层，这样仓储才可以把领域逻辑执行完后，才可能将
领域对象持久化到数据库中，这一点与传统的架构有本质的区别。
一般我们会在解决方案中建立一个项目，这个项目就是包含了所有聚合的仓储实现，具体不同上下文的仓储实现，可以在这个项目下建立不同的文件夹。
1.产

DDD实战进阶第一波(六)：开发一般业务的大健康行业直销系统（实现产品上下文仓储与应用服务层）

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

腾讯云开发者社区推出了领域驱动设计DDD实战进阶专栏，为你提供了领域驱动设计DDD实战进阶的相关文章，致力于帮助开发者快速成长与发展。

领域驱动设计DDD实战进阶

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐