基于 DDD 的微服务设计演示
### 基于 DDD 的微服务设计演示 [TOC] #### 单 Service 实现数据查询 用单 Service 注入不同的 Dao，实现各种不同的查询。 > 大数据相关产品，运用大数据技术对海量的数据进行分析处理，并且最终的结果是通过各种报表来查询并展示。因此这些项目除了后台的各种分析处理以外，还要在前段展现各种报表，而且这些报表非常多且繁杂。同时，使用这个系统的都是决策型领
如何实现支持快速交付的技术中台战略
## 如何实现支持快速交付的技术中台战略 以往建设的系统都分为前台和后台，前台是与用户交互的UI界面,后台是服务端完成的业务逻辑操作。然而在我开发的很多系统中，有一些内容是共用的部分，在未来的开发系统中也要使用到，所以如果能把内容提取出来，做成共用主键，那么在未来开发系统就简单了，不用每次都重头开发。 > 公用的组件既包含前台的界面，也包含后台的逻辑，被称为“中台”。 > > 中台
DDD 是如何解决微服务拆分的难题
## DDD 是如何解决微服务拆分的难题 将微服务落地到具体的业务中，真正的难题是`微服务按照说明原则拆分、如何拆分以及会面对哪些潜在风险` > 微服务的拆分原则--“小而专”即微服务内高内聚、微服务间低耦合 > > 微服务的高内聚：就是单一职责原则，将代码修改的范围缩小到这个微服务内 > > 微服务间低耦合：在微服务实现自身业务的过程中，如果需要执行的某些过程不是自己的职责，
如何开事件风暴会议
## 如何开事件风暴会议 微服务设计最核心的难题是`微服务拆分`，要讲究“小而专”的设计，要“低耦合、高内聚”。这里以在线订餐系统项目来进行实战邻域模型设计。 ![image-20210904153156351](https://mufeng-blog.oss-cn-beijing.aliyuncs.com/typecho/image-20210904153156351.png
限界上下文
## 限界上下文 在软件设计中，复杂系统中包含了那么多的场景，每个场景都包含了那么多的邻域对象，并且每个邻域对象中还存在那么多的复杂关系，我们对系统的领域模型该如何设计？ ### 问题域和限界上下文 首先，我们应该将整个系统划分成许多相对独立的业务场景，在一个个的业务场景中进行邻域分析与建模，这样的业务场景称之为“问题子域”，简称“子域”。 邻域驱动核心的设计思想--将对软
聚合、仓库与工厂
## 聚合、仓库与工厂 [TOC] 领域模型的最终设计可以落实到服务、实体和值对象 ### 服务 标识的是在领域对象之外的操作与行为，接收用户的请求和执行某些操作 当用户在操作界面中进行操作时，会向系统发送请求，“服务”去接收用户的这些请求，让后根据需求去执行相应的方法，所有操作都完成后，再将实体或值对象中的数据持久化到数据库中 ### 实体 通过一个唯一标识