工作一段时间后，业务设计和数据库设计反而难下手了，有没有好建议？

[shinelamla]

每次需求交到自己手上，对于业务设计和数据库设计都感觉比较难下手，要么：

1. 设计不够合理，需要重来
2. 设计方案性能不够高或者后期维护麻烦
3. 另外的同事来做的话，会有更好的抽象，更合理的分层

想解决一下目前的困境，大家有没有相关的书籍或者资料推荐学习一下？

[JoeDH]

先确定需求以及原型稿，然后根据需求确定功能结构图、信息结构图、业务流程图，照这些大概就能得出来一个概要设计了，然后跟产品或领导对齐细化，基本就可以开工了。 最重要是对齐，然后获取方案认可，不要闷头干。
这就是最基本的流程，DDD 应该还太抽象了，如果你要看书那也有一本，最近我刚看的《软件设计:从专业到卓越》

[mccormickclariss]

@niubee1 非常赞同！

[yuanmomo]

@yueyuea 这个是我喜欢的答案

[chf007]

想得太多了

[shinelamla]

最终发现没有很好的方法论，都是经验，做多了业务就慢慢触类旁通了。没有办法很好地总结，如果有，不一早就有人分享出来了？为什么这这方面的资料这么少？

[levelworm]

倒还不如问问看同事他是怎么做的。

[joApioVVx4M4X6Rf]

遇到过和你一样的情况。我选择看了很多 UML 的书，什么火球 UML 大象 UML ，又看了 DDD 各种书，又看买了极客时间的各种 DDD 的课程，浪费了很多很多时间，但是收获很少，每天都很纠结，写不出来代码，需求甚至延期。最后恍然大悟，脱离了目标谈抽象，永无止境，永远有更好的抽象。最近我发现思考“公司的业务是怎么跑起来的，钱是怎么赚的”，比技术好玩儿多了~ 如果楼主有更好的资料，求分享一波，我还是想知道怎么才能设计出更好的东西

[NewMoorj]

你比小白更加慎重，因为你见过一些坑，现在你在设计模型时会想办法避免这些坑。

这就是个经验积累的过程，很正常。

[NewMoorj]

看到楼主说是求术的，很遗憾，没有捷径，任何写代码三五年的人，看自己第一年的代码，都会像看屎一样。

[panlatent]

DDD 当然值得借鉴，但更多的时候，从 0-1 设计会容易让项目陷入泥潭。我建议是在一种较成熟普遍，易于拓展和修改的设计上，先让代码落地，不断微调。大概可以叫渐进式设计 。

理由就是我意识到自己的认知和能力有限，一下画不出一张大饼

[julyclyde]

终于从技术回归科学了

[xianzhe]

我觉得 27 楼的兄弟说的在理，设计出来好东西是不会凭空冒出来的，与其纠结怎样是好的，不如先快速试错，多迭代。世界的本质就是个草台班子，设计的再好抵不住人家早就把功能上线收客户钱了。

[zartouch]

这东西还是需要些经验的。

1. 很多时候设计的不好很大一部分是对业务需求理解不够。设计之前多花时间梳理业务，整理 use case ，画流程图，然后再分模块。 如果业务没理解好，后面的都白搭。
2. 好的系统不是设计出来的而是迭代出来的，特别是复杂的业务系统，很少有人能一开始就设计的很完善，大部分还是根据业务理解加深和新需求的变化，不断完善起来的。你同事能做好也是因为之前类似的经验，踩过坑了。这里你可以自己想过以后多和你同事讨论。重点是思考为什么自己一开始想不到这些点。
3. 去 github 上搜你这个领域的代码，或者就是看公司好的项目代码，多思考为什么这么设计，特别是结合业务来看。 这本质是要提升你自己的思考问题的方式和角度，这个只能多想多练。

一些关于架构，DDD 之类的书，我建议有点自己的思考再看，你现在看了只会有个似是而非的印象，踩过坑之前，很难深刻理解那么做的意义。当然一些基础的设计概念的书籍如 clean code ，设计模式，重构这类的我默认是肯定读过的，否则完全没有理论基础单纯靠经验那也是扯谈，容易走成野路子。

[x2ve]

过早优化杀死积极性

[lizy0329]

大道至简，那些什么 DDD 只会坑死你不偿命，MVC 才是唯一真神