# star-sample-ddd

**Repository Path**: java-samples/star-sample-ddd

## Basic Information

- **Project Name**: star-sample-ddd
- **Description**: 领域驱动设计样板工程
- **Primary Language**: Java
- **License**: Apache-2.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 2
- **Created**: 2021-02-18
- **Last Updated**: 2021-12-18

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

#  ddd-sample

#### 介绍
领域驱动设计(DDD)项目样板工程

### client 客户端层

职责：用于外部依赖，作为客户端请求远程调用过程服务(RPC)所用。

ddd-client包含了对外接口、数据传输对象(DTO)、枚举类

api（Application Programming Interface，应用程序接口）一些预先定义的接口，用来提供应用程序与开发人员基于某软件或硬件得以访问的一组例程，而又无需访问源码，或理解内部工作机制的细节。
dto (Data Transfer Object，数据传输对象) DTO也常被称作值对象, VO,实质上与领域层的VO并不相同，DTO是数据传输的载体,内部不应该存在任何业务逻辑,通过DTO把内部的领域对象与外界隔离。 
分为请求传输对象(request)、结果传输对象(result)、普通数据传输对象(DTO)
enums (枚举) 存放的是客户端中会用到的一些业务的状态、类型等枚举类

### interfaces 用户界面层（或表示层）  最顶层

职责：负责向用户显示信息和解释用户命令

ddd-interfaces 对外接口类的实现，包括HSF、MTOP、TOP、定时任务、消息等等多种来源。 

用法：1.请求应用层以获取用户所需要展现的数据(比如获取首页的商品数据)
     2.发送命令给应用层要求其执行某个用户命令(实现某个业务逻辑,比如用户要进行转账)
     
assembler (装配器): 实现DTO与领域对象之间的相互转换,数据交换,因此Assembler几乎总是同DTO一起出现。
facade (门面): Façade的用意在于为远程客户端提供粗粒度的调用接口，它的主要工作就是将一个用户请求委派给一个或多个Service进行处理,也就是我们常说的Controller。

待定 注：通过CQRS的架构，我们做到了interface和application之间的解耦，所以interface只依赖了中间件和client包。

DDD分层模型的类型转换，DTO -> Creator(防护 domain entity) -> Entity <-> PO

### infrastructure 基础实施层  最底层(但与所有层进行交互)

职责：向其他层提供通用的 技术能力(比如工具类,第三方库类支持,常用基本配置,数据访问底层实现)，定义物理模型

主要是Repository的实现、DAO、数据映射对象DO（Data Object），DO和Entity的转化类等。Infrastructure只依赖数据库、Tair等跟存储相关的依赖，以及Domain层，不依赖Application层。

 基础实施层主要包含以下的内容:
        为应用层 传递消息(比如通知)
        为领域层 提供持久化机制(最底层的实现)
        为用户界面层 提供组件配置
        基础设施层还能够通过架构框架来支持四个层次间的交互模式。
  
   cache 缓存的实现
   dao   数据库访问的实现
   lock  锁的实现
   mq    消息的实现
  
   translator 翻译，转换
   
### application 应用服务层
 
 职责：应用层定义了软件要完成的任务，要尽量简单。(相对于领域层,应用层是很薄的一层)
 
 业务流程的封装，包括了应用服务（Application Service）、DTO转化器等传统Application层包含的东西。同时在这次架构升级中，引入了业务流程可视化的元素，详细在后面讲。Application层在原则上只做业务流程的编排，不做核心业务逻辑，所有判断必须下沉到Domain层。
 
 用法：1.它不包含任务业务规则或知识, 为下一层的领域对象协助任务、委托工作。
      2.它没有反映业务情况的状态,但它可以具有反映用户或程序的某个任务的进展状态。
      3.对外为展现层提供各种应用功能(service)。
      4.对内调用领域层（领域对象或领域服务）完成各种业务逻辑任务(task)。
      5.这一层也很适合写一些任务处理,日志监控。

### domain 领域服务层

职责：负责表达业务概念,业务状态信息和业务规则。

核心业务逻辑的承载，包括了实体（Entity）和聚合根（Aggregate）、有业务属性的值对象（Domain Primitive）、域服务（Domain Service）、和Repository的接口类。Domain只依赖Client、外部二方包的Facade接口，不依赖任何其他框架（包括Spring）。这就确保了Domain层是完整可单测的。

用法：1.Domain层是整个系统的核心层,几乎全部的业务逻辑会在该层实现。

领域模型层主要包含以下的内容:
        实体(Entities):具有唯一标识的对象
        值对象(Value Objects): 无需唯一标识的对象
        领域服务(Domain Services): 一些行为无法归类到实体对象或值对象上,本质是一些操作,而非事物
        聚合/聚合根(Aggregates,Aggregate Roots):
        聚合是指一组具有内聚关系的相关对象的集合,每个聚合都有一个root和boundary
        工厂(Factories): 创建复杂对象,隐藏创建细节
        资源库(Repository): 提供查找和持久化对象的方法
        技术规范（specification）：提供技术规范,为外部暴露扩展（考虑是否提出domain，单建模块）
 
### plugin 插件层

职责：业务中台，插件扩展，用于新增业务的扩展实现
 
### specification 技术规范层

职责：制定技术规范，用于新增业务的扩展实现

specification 充当防腐作用，通过依赖倒置定义基础设施层需要实现的技术细节接口

### 其它

 依赖倒置：
 DDD Domain层和Infrastructure的粘合剂：通过依赖倒置.
 
 domain层声明需要基础设施层实现的接口：RPC, DB, Cache, MQ等
 为了方便产品人员查看领域层代码，梳理业务，统一放在facade package，减少对产品同学的干扰
 这样，domain层才能主宰世界，成为系统的中心：它要求Infrastructure做到什么
 至于如何做到，domain层不关心：那是技术的事情，domain只负责业务逻辑
 
 扩展点：
 扩展点，是通过注解方式注册寻找。
 注册后的扩展点，具有不同的能力。使用时，直接查询有没有这个能力，有就使用。
 利用动态代理，执行
 
 流程编排：
 通过能力扩展点，在根据提前编排好的执行步骤，进行具体执行

### DDD相关概念知识

1.聚合的管理：聚合根、实体和值对象的关系。

2.聚合数据的初始化和持久化：工厂和仓储模式。

3.聚合的解耦：聚合代码的解耦、跨聚合的服务调用和对象解耦。

4.领域事件管理：领域事件实体结构、持久化和事件发布。

5.DDD分层架构：基础层、领域层、应用层和用户接口层的协作。

6.服务的分层与协作：实体方法、领域服务、应用服务、接口服务，服务的组合和编排，跨多个聚合的服务管理和协同。

7.对象的分层和转换：DTO、DO和PO等对象在不同层的转换和实现过程。

8.微服务之间的访问：登录和认证服务。


目录

如何运行该演示

演示代码入口

项目基本介绍

代码快速入门

代码结构
    依赖关系
    
搭建工程骨架

业务术语解释

上线打包
-------------------
##### 设置版本号：
    mvn versions:set -DnewVersion=1.0.0-SNAPSHOT

##### 编译打包发布：
    mvn clean compile deploy -Dmaven.test.skip=true

application 模块，编排领域服务，在 use case 层实现该API
test 模块，单元测试模块，主要针对domain层编写测试用例

一个应用有N个业务方，每个业务方有N个租户
基于此，如果用if-else判断业务差异，那就悲催了。此时需要扩展点或者叫插件。