基于 DDD 的微服务设计演示
### 基于 DDD 的微服务设计演示 [TOC] #### 单 Service 实现数据查询 用单 Service 注入不同的 Dao,实现各种不同的查询。 > 大数据相关产品,运用大数据技术对海量的数据进行分析处理,并且最终的结果是通过各种报表来查询并展示。因此这些项目除了后台的各种分析处理以外,还要在前段展现各种报表,而且这些报表非常多且繁杂。同时,使用这个系统的都是决策型领
### 基于 DDD 的微服务设计演示 [TOC] #### 单 Service 实现数据查询 用单 Service 注入不同的 Dao,实现各种不同的查询。 > 大数据相关产品,运用大数据技术对海量的数据进行分析处理,并且最终的结果是通过各种报表来查询并展示。因此这些项目除了后台的各种分析处理以外,还要在前段展现各种报表,而且这些报表非常多且繁杂。同时,使用这个系统的都是决策型领
## 如何实现支持快速交付的技术中台战略 以往建设的系统都分为前台和后台,前台是与用户交互的UI界面,后台是服务端完成的业务逻辑操作。然而在我开发的很多系统中,有一些内容是共用的部分,在未来的开发系统中也要使用到,所以如果能把内容提取出来,做成共用主键,那么在未来开发系统就简单了,不用每次都重头开发。 > 公用的组件既包含前台的界面,也包含后台的逻辑,被称为“中台”。 > > 中台
## DDD 是如何解决微服务拆分的难题 将微服务落地到具体的业务中,真正的难题是`微服务按照说明原则拆分、如何拆分以及会面对哪些潜在风险` > 微服务的拆分原则--“小而专”即微服务内高内聚、微服务间低耦合 > > 微服务的高内聚:就是单一职责原则,将代码修改的范围缩小到这个微服务内 > > 微服务间低耦合:在微服务实现自身业务的过程中,如果需要执行的某些过程不是自己的职责,
## 如何开事件风暴会议 微服务设计最核心的难题是`微服务拆分`,要讲究“小而专”的设计,要“低耦合、高内聚”。这里以在线订餐系统项目来进行实战邻域模型设计。  ```shell # 拉取 mongo 镜像 $ docker pull mongo # 创建 mongodb 数据保存目录 $ mkdir /var/mongodata # 创建并运行 m