|
1 | 1 | 怎样拆分系统为微服务
|
2 | 2 | ===============
|
3 | 3 | - [怎样拆分系统为微服务](#怎样拆分系统为微服务)
|
4 |
| - - [1. 何为架构? 有哪些架构风格?](#1-何为架构-有哪些架构风格) |
5 |
| - - [2. 动手拆分](#2-动手拆分) |
6 |
| - - [2.1 按业务拆分](#21-按业务拆分) |
7 |
| - - [2.2 按子领域拆分](#22-按子领域拆分) |
8 |
| - - [2.3 拆分原则](#23-拆分原则) |
9 |
| - - [SINGLE RESPONSIBILITY PRINCIPLE(单一职责原则)](#single-responsibility-principle单一职责原则) |
10 |
| - - [COMMON CLOSURE PRINCIPLE(共同封闭原则)](#common-closure-principle共同封闭原则) |
11 |
| - - [2.4 拆分可能会遇到的障碍](#24-拆分可能会遇到的障碍) |
12 |
| - - [2.5 定义服务接口](#25-定义服务接口) |
| 4 | + - [1. 何为架构?](#1-何为架构) |
| 5 | + - [2. 有哪些架构风格?](#2-有哪些架构风格) |
| 6 | + - [3. 动手拆分](#3-动手拆分) |
| 7 | + - [3.1 按业务拆分](#31-按业务拆分) |
| 8 | + - [3.2 按子领域拆分](#32-按子领域拆分) |
| 9 | + - [3.3 拆分原则](#33-拆分原则) |
| 10 | + - [SINGLE RESPONSIBILITY PRINCIPLE(单一职责原则)](#single-responsibility-principle单一职责原则) |
| 11 | + - [COMMON CLOSURE PRINCIPLE(共同封闭原则)](#common-closure-principle共同封闭原则) |
| 12 | + - [3.4 拆分可能会遇到的障碍](#34-拆分可能会遇到的障碍) |
| 13 | + - [3.5 定义服务接口](#35-定义服务接口) |
| 14 | + - [相关书籍](#相关书籍) |
13 | 15 |
|
14 | 16 |
|
15 |
| -## 1. 何为架构? 有哪些架构风格? |
16 |
| -## 2. 动手拆分 |
| 17 | +## 1. 何为架构? |
17 | 18 |
|
18 |
| -### 2.1 按业务拆分 |
| 19 | +>The software architecture of a computing system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both. |
| 20 | +
|
| 21 | + |
| 22 | +1. 从四个纬度来看 |
| 23 | + |
| 24 | + |
| 25 | + |
| 26 | +1. 为什么要有架构? |
| 27 | + |
| 28 | +可伸缩、可靠性、安全性、可快速的交付 |
| 29 | + |
| 30 | +## 2. 有哪些架构风格? |
| 31 | + |
| 32 | +三层架构、六边形架构、微服务架构 |
| 33 | + |
| 34 | +## 3. 动手拆分 |
| 35 | + |
| 36 | +user story |
| 37 | + |
| 38 | +1个user story可能会有多个场景, 场景pre-conditions 和 post-conditions |
| 39 | + |
| 40 | + |
| 41 | +user story 能产生 |
| 42 | + |
| 43 | + domain model & operation |
| 44 | + |
| 45 | +### 3.1 按业务拆分 |
19 | 46 |
|
20 | 47 | 比如, 在线电商, 订单管理,库存管理,发货管理。
|
21 | 48 |
|
22 | 49 | 
|
23 | 50 |
|
24 | 51 |
|
25 |
| -## 2.2 按子领域拆分 |
| 52 | +## 3.2 按子领域拆分 |
26 | 53 |
|
| 54 | + |
27 | 55 |
|
28 | 56 | DDD(领域驱动设计,Domain driven design)
|
29 | 57 |
|
30 |
| -子领域 |
| 58 | +1. 领域和子领域 |
| 59 | + |
| 60 | +核心领域、通用子域、支撑子域 |
31 | 61 |
|
32 |
| -限界上下文 |
| 62 | + |
| 63 | +2. 限界上下文 |
33 | 64 |
|
34 | 65 | 
|
35 | 66 |
|
36 |
| -## 2.3 拆分原则 |
| 67 | +3. 实体和值对象 |
| 68 | + |
| 69 | +4. 聚合和聚合根 |
| 70 | + |
| 71 | +仓储模式、工厂模式 |
37 | 72 |
|
38 |
| -## SINGLE RESPONSIBILITY PRINCIPLE(单一职责原则) |
| 73 | +5. 领域事件 |
| 74 | + |
| 75 | +6. DDD分层架构 |
39 | 76 |
|
40 |
| -## COMMON CLOSURE PRINCIPLE(共同封闭原则) |
| 77 | +六边形架构 |
41 | 78 |
|
| 79 | +## 3.3 拆分原则 |
42 | 80 |
|
43 |
| -## 2.4 拆分可能会遇到的障碍 |
| 81 | +### SINGLE RESPONSIBILITY PRINCIPLE(单一职责原则) |
| 82 | + |
| 83 | +### COMMON CLOSURE PRINCIPLE(共同封闭原则) |
| 84 | + |
| 85 | +## 3.4 拆分可能会遇到的障碍 |
44 | 86 |
|
45 | 87 | * 网络延迟
|
46 | 88 | * 因为同步调用减少可用性
|
47 | 89 | * 获取一致的数据
|
48 | 90 | * 神类问题
|
49 | 91 |
|
50 |
| -## 2.5 定义服务接口 |
| 92 | +## 3.5 定义服务接口 |
51 | 93 |
|
52 | 94 | 分为两种, 操作(既有系统级的操作,也有服务之间的协同), 事件(多用于服务间的数据协同)。
|
53 | 95 |
|
54 |
| - |
| 96 | + |
| 97 | + |
| 98 | +## 相关书籍 |
| 99 | + |
| 100 | +* 实现领域驱动设计 |
| 101 | +* 中台架构与实现 |
| 102 | + |
0 commit comments