前一篇文章我们介绍了如何将创建产品的领域逻辑与产品的持久化仓储通过上架产品的用例组织起来，完成了一个功能。在实际的项目中，多种前端的形态比如PC Web、 微信小程序、原生APP等要调用后端的功能，通常要将后端的功能包装成RESTFUL风格，这样前端就可以使用Http Get或Post方式调用 ...

从这篇文章开始，我们开始介绍大健康行业直销系统领域层的实现。 先简单讲下业务方面的需求：直销系统会有一个顶级的经销商，经销商的基本信息中包括经销商的名字、联系人(因为在平台购买产品后，会寄送给联系人)、总的电子币（电子币是由经销商支付产生， 购买产品后会扣减电子币）、总的奖金币（系统周期性 ...

前一篇文章我们完成了产品上下文的领域层，我们已经有了关于产品方面的简单领域逻辑，我们接着来实现产品上下文关于仓储持久化与应用层的用例如何来协调 领域逻辑与仓储持久化。 首先大家需要明确的是，产品上下文的领域逻辑是系统的核心，它不应该依赖仓储，而仓储应该要依赖领域层，这样仓储才可以把领域逻辑执行 ...

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

上篇文章主要讲述了经销商上下文的需求与POCO对象，这篇文章主要讲述该界限上下文的仓储与领域逻辑的实现。 关于界限上下文与EF Core数据访问上下文参考产品上下文相应的实现，这里不再累述。 因为在经销商上下文中有两个聚合，一个是经销商聚合，一个是登录聚合，所以我们需要实现两个仓储接口 ...

在本系列前面的文章中，我们主要讨论了产品上下文与经销商上下文相关的实现，大家对DDD的方法与架构已经有了初步的了解。 但是在这两个界限上下文中，业务逻辑很简单，也没有用到更多的值对象的内容。从这篇文章开始，我们来讲讲订单界限上下文实现的内容， 里面的业务逻辑相对复杂一些，而且有大量值对象的引入 ...

本系列文章 DDD实战进阶第一波(一)：开发一般业务的大健康行业直销系统（概述） DDD实战进阶第一波(二)：开发一般业务的大健康行业直销系统（搭建支持DDD的轻量级框架一） 近年来，关于如何开发基于业务的软件系统与产品一直是软件行业的一个重要内容。对于架构师与软件开发人员来说，开发此类系统 ...

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