这是一个创建于 261 天前的主题，其中的信息可能已经有所发展或是发生改变。
每次需求交到自己手上，对于业务设计和数据库设计都感觉比较难下手，要么：
- 设计不够合理，需要重来
- 设计方案性能不够高或者后期维护麻烦
- 另外的同事来做的话，会有更好的抽象，更合理的分层
想解决一下目前的困境，大家有没有相关的书籍或者资料推荐学习一下？
第 1 条附言 · 261 天前
发帖的目的是来求术的，而不是来求道的。麻烦大家给具体方向或者数据，分享 道 的大佬们可以先不发言了~等我到了那个层次再来求教~
35 条回复 • 2024-04-15 09:42:55 +08:00
 |
1
skyemin 261 天前
看看 DDD
|
 |
2
Jack66 261 天前
从简入难，mvc 多看表设计
|
 |
3
xiangxiangxiang 261 天前
@skyemin 麻烦问下有书籍推荐的吗？
|
 |
4
yule111222 261 天前  5
《解构领域驱动设计》
《架构整洁之道》 《分析模式：可复用的对象模型》 |
 |
5
F7TsdQL45E0jmoiG 261 天前
逻辑、抽象、复用，思维体系三基石
|
 |
6
shinelamla OP @morenacl 有没有具体的？
|
|
7
shinelamla OP @yule111222 像这种回答应该被推荐
|
 |
8
afxcn 261 天前
理清楚业务之间的关系应该不是件难的事情，难以下手往往是想太多，过度设计。
|
 |
9
securityCoding 261 天前
找准两三个开源项目彻底吃透
|
 |
10
woodwhales 261 天前 1
可以先看现已上线的系统功能需求，想想自己来设计会怎么设计库表及代码结构。然后看现有代码怎么实现的，存在不合理和合理的，一目了然。
如果项目没有现成的已实现功能，可以列出自己的思路，找同事私下把把关，探讨一下。 最后再配合楼上说的书籍加深理解，上来就看书，太理论，个人觉得对新人不友好。 |
 |
11
cstj0505 261 天前
如果不是交易系统那种一点不能错的我反而不重视数据库设计,包括三范式也不遵循,关系数据库里大量用到 json 字符串,外键也不用.
我觉得关系模型太繁琐了. |
 |
12
NessajCN 261 天前
https://www.mongodb.com/basics/database-architecture
你问的太宽泛了，那我也只好宽泛地说根据需要选 Tier1~3 的架构 至于具体选哪个 tier ，选好了之后怎么设计各个 layer ，得结合实际业务来 |
|
13
shinelamla OP @woodwhales 谢谢，挺好的建议
|
 |
14
nothingistrue 261 天前 3
内练：《实现领域驱动设计》(Vaughn Vernon 著， 滕云 译) （要准备上几年慢慢练，不然容易走火入魔。）
外练：Entity Relation Diagram/Design/Modeling 。相关参考如下： 方法 https://www.cnblogs.com/muchen/p/5258197.html 关系的名称和方向 https://stackoverflow.com/questions/15941149/how-we-identify-the-relation-direction-in-an-er-diagram-if-we-use-chens-notation 陈氏表示法 https://vertabelo.com/blog/chen-erd-notation/ 乌鸦脚表示法（多重性上一般不用原始陈氏表示法而换用乌鸦脚表示法） https://vertabelo.com/blog/crow-s-foot-notation/ 请注意：不管是 DDD ,还是 ERD ,都不是单纯的技术设计，而是业务模型设计，产品/需求也是要参与的。如果产品/需求压根不管你啥模型，就盯着界面原型甚至效果图，还拒绝被模型引导，那你搞啥都不管用。 |
 |
15
pkoukk 261 天前
我的理解是，数据和数据库是不同的，先理业务，理解你的数据流
让数据走通整个流程，当你做完这一切的时候 数据库只是最后保存的那一下，没什么难度了 |
 |
16
ZhuWenJian 261 天前
业务设计可以用状态归类。
举个（前端）列子：实现一个具备多选、删除、全选的列表。 页面按钮：返回、关闭、多选、全选、item 选择、删除。 可以想想怎么设计合理。 |
 |
17
tianzx 261 天前
1 、设计不够合理，需要重来 ：不需要设计的面面俱到，KISS 原则。就是先把一个模块最核心的东西设计出来。剩余的字段和相对资深的同事、架构师去讨论。
2 、设计方案性能不够高或者后期维护麻烦 ：1 、性能不够高 ：这个是需要基础架构、业务架构的支持 。比如支持容器的扩缩容、读写分离、多级缓存、数据一致性 、分库分表 、是否需要反范式、索引是否合理、是否有数据倾斜和热点问题 2 、后期维护麻烦 ：多想 1-2 步即可，比如需要多加一个字段、多支持一种业务形态。 3 、另外的同事来做的话，会有更好的抽象，更合理的分层 ：1 、多去问，如果你来设计会怎么想。和你的对比下，慢慢积累经验，业务架构不可能一簇而就。 4 、唯一推荐：DDIA 。仔细读 3 遍 |
 |
18
piecezzz 261 天前
不可能一步到位的，做个相对合理的 case 就行
|
 |
19
niubee1 261 天前 7
首先你需要先从建模开始入手，合理的模型才能高效的驱动业务，然后模型的持久化，数据库只是一种选择，文件，redis ，远程 API 也可以是持久化的一部分，把适合数据库的部分拿出来，再来说数据库表设计，数据库表和模型实体之间并不是严格的一比一的关系，虽然很多时候是一比一。一般来说基本原则还是遵循 3NF 范式，但是在某些地方，根据模型和业务的实际情况，需要做一个些反范式的设计，比如某些在 3NF 范式下 JOIN 深度超过 2 层的地方，用冗余字段降低到 2NF 范式，某些模型实体比较大的，根据访问频次，可能会切分成几个表，比如用户，用户的登陆信息和用户的属性就需要切分成两个表来存储，如果有一些统计字段，也会单独用一个表来存，因为登陆信息一旦插入，几乎很少修改，而属性则因为运营关系经常有需求会修改加字段，这个时候分开表就不容易被卡住。有用户的统计字段的话，因为经常性的更新统计信息，这个表比较热，所以更需要和其他几个表分开，这样保证了 1 ，模型的完整性 2 ，可扩展性 3 ，效率。做好设计后在纸上预跑一遍，不要依赖就急吼吼的拿起工具就建表，预跑一遍，把 SQL 写出来，然后才好规划索引，另外就是根据实际的业务来计算一下预计的容量，也是你系统的设计容量，比如有的表撑死了也就几百条一千吧条数据，那你除了主键外都没有必要建多余的索引。有的表预计记录条数超多，那么提前考虑好是否需要分表，分库。
在真实世界里完美的设计是不存在的，因为其实完美的需求是不存在的，而好的设计和坏的设计的区别就在于如何取舍上，这个问题貌似没有哪本书能给你完美的答案。认识一个家伙特别喜欢买书，各类大作堆了一墙，但是能看完的，本就不多，看完了的，貌似也没啥用，搞数据库设计还是稀烂，经常扯到蛋（还是客户端的数据库） |
 |
20
yueyuea 261 天前
既然你已经明确了另外的同事来做的话，会有更好的抽象，更合理的分层，你就去学习，思考别人为什么会这么做，这个过程比无脑看书更有意义。
|
 |
21
JoeDH 261 天前 via Android
先确定需求以及原型稿，然后根据需求确定功能结构图、信息结构图、业务流程图，照这些大概就能得出来一个概要设计了，然后跟产品或领导对齐细化，基本就可以开工了。 最重要是对齐，然后获取方案认可，不要闷头干。
这就是最基本的流程，DDD 应该还太抽象了，如果你要看书那也有一本，最近我刚看的《软件设计:从专业到卓越》 |
 |
22
mccormickclariss 261 天前
@niubee1 非常赞同！
|
 |
24
chf007 261 天前
想得太多了
|
|
25
shinelamla OP 最终发现没有很好的方法论，都是经验，做多了业务就慢慢触类旁通了。没有办法很好地总结，如果有，不一早就有人分享出来了？为什么这这方面的资料这么少？
|
 |
26
levelworm 260 天前
倒还不如问问看同事他是怎么做的。
|
 |
27
joApioVVx4M4X6Rf 260 天前
遇到过和你一样的情况。我选择看了很多 UML 的书，什么火球 UML 大象 UML ，又看了 DDD 各种书，又看买了极客时间的各种 DDD 的课程，浪费了很多很多时间，但是收获很少，每天都很纠结，写不出来代码，需求甚至延期。最后恍然大悟，脱离了目标谈抽象，永无止境，永远有更好的抽象。最近我发现思考“公司的业务是怎么跑起来的，钱是怎么赚的”，比技术好玩儿多了~ 如果楼主有更好的资料，求分享一波，我还是想知道怎么才能设计出更好的东西
|
 |
28
NewMoorj 260 天前
你比小白更加慎重，因为你见过一些坑，现在你在设计模型时会想办法避免这些坑。
这就是个经验积累的过程，很正常。 |
|
29
NewMoorj 260 天前
看到楼主说是求术的，很遗憾，没有捷径，任何写代码三五年的人，看自己第一年的代码，都会像看屎一样。
|
 |
30
panlatent 260 天前 via Android
DDD 当然值得借鉴，但更多的时候，从 0-1 设计会容易让项目陷入泥潭。我建议是在一种较成熟普遍，易于拓展和修改的设计上，先让代码落地，不断微调。大概可以叫渐进式设计 。
理由就是我意识到自己的认知和能力有限，一下画不出一张大饼 |
 |
31
julyclyde 260 天前
终于从技术回归科学了
|
 |
32
xianzhe 260 天前 1
我觉得 27 楼的兄弟说的在理，设计出来好东西是不会凭空冒出来的，与其纠结怎样是好的，不如先快速试错，多迭代。世界的本质就是个草台班子，设计的再好抵不住人家早就把功能上线收客户钱了。
|
 |
33
zartouch 259 天前
这东西还是需要些经验的。
1. 很多时候设计的不好很大一部分是对业务需求理解不够。设计之前多花时间梳理业务，整理 use case ，画流程图，然后再分模块。 如果业务没理解好，后面的都白搭。 2. 好的系统不是设计出来的而是迭代出来的，特别是复杂的业务系统，很少有人能一开始就设计的很完善，大部分还是根据业务理解加深和新需求的变化，不断完善起来的。你同事能做好也是因为之前类似的经验，踩过坑了。这里你可以自己想过以后多和你同事讨论。重点是思考为什么自己一开始想不到这些点。 3. 去 github 上搜你这个领域的代码，或者就是看公司好的项目代码，多思考为什么这么设计，特别是结合业务来看。 这本质是要提升你自己的思考问题的方式和角度，这个只能多想多练。 一些关于架构，DDD 之类的书，我建议有点自己的思考再看，你现在看了只会有个似是而非的印象，踩过坑之前，很难深刻理解那么做的意义。当然一些基础的设计概念的书籍如 clean code ，设计模式，重构这类的我默认是肯定读过的，否则完全没有理论基础单纯靠经验那也是扯谈，容易走成野路子。 |
 |
34
x2ve 258 天前 via iPhone 1
过早优化杀死积极性
|
 |
35
lizy0329 258 天前
大道至简，那些什么 DDD 只会坑死你不偿命，MVC 才是唯一真神
|
Select Language