在之前的若干博客中，都提出了一个观点：数据是由 ID 和 Content 构成的。然而数据从来都不是单独存在的，数据与数据之间存在者复杂的关系。每一种数据都有一个 概念（也可称之为：名称、实体、对象）。数据与数据之间存在着 关系。本文要梳理的点就是系统设计中的概念与关系。
概念
在 RESTful API 设计中有一句话 资源在网络中以某种表现形式进行状态转移。数据在不同的的业务之间不停的流动，在用户端，数据可以是网页，也可以是原生界面；在业务系统中，使用对象来承载数据，使用函数操作数据；在存储系统中，数据被持久化为三种形态：
- 键值对（K-V）
- 集合/表格（Table）
- 关系型数据（介于K-V与Table之间）
数据命名的好坏，代表了开发人员对于数据理解的深度。概念不清，概念之间的关系自然无从谈起。
关系
对象之间的关系，有且只有两种：
- 并列关系（Sibling）
- 父子关系（Parent-Child）
一组对象形成一棵树（Tree），若干颗关系密切的树形成整个森林（Forest），一个森林就是一个系统。在持久化的过程中，通过对象映射关系（ORM），数据从业务系统的对象中转移到存储系统中。
数据之间的有关系，有且仅有三种：
- 一对一（One-to-One）
- 一对多（One-to-Many）
- 多对多（Many-to-Many）
自上而下，在系统中的表达的难度依次增加，系统的复杂度也就越高。自下而上，下面的关系总能用来表示上面的关系，因此更具表达能力。
设计
业务系统设计的重点在于赋予 概念，梳理 关系，以及在满足业务需求的前提下，尽量简化 关系。关系越简单，系统越简单；系统越简单，开发和维护的难度也就越低。当然，表达能力也就越低。如果说设计有三个层次，那么这三个层次是：
- 梳理清楚概念与关系
- 简化关系的能力
- 复杂化关系以表达业务需求
从产品角度考虑，拥抱关系复杂化，是开发人员设计成熟的标识。
本文作者 ： cyningsun
本文地址 ： https://www.cyningsun.com/12-15-2020/system-design-concept-and-relation.html
版权声明 ：本博客所有文章除特别声明外，均采用 CC BY-NC-ND 3.0 CN 许可协议。转载请注明出处！
