V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
shinelamla
V2EX  ›  程序员

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

  •  
  •   shinelamla · 39 天前 · 4202 次点击
    这是一个创建于 39 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

    第 1 条附言  ·  39 天前
    发帖的目的是来求术的,而不是来求道的。麻烦大家给具体方向或者数据,分享 道 的大佬们可以先不发言了~等我到了那个层次再来求教~
    35 条回复    2024-04-15 09:42:55 +08:00
    skyemin
        1
    skyemin  
       39 天前
    看看 DDD
    Jack66
        2
    Jack66  
       39 天前
    从简入难,mvc 多看表设计
    xiangxiangxiang
        3
    xiangxiangxiang  
       39 天前
    @skyemin 麻烦问下有书籍推荐的吗?
    yule111222
        4
    yule111222  
       39 天前   ❤️ 5
    《解构领域驱动设计》
    《架构整洁之道》
    《分析模式:可复用的对象模型》
    morenacl
        5
    morenacl  
       39 天前
    逻辑、抽象、复用,思维体系三基石
    shinelamla
        6
    shinelamla  
    OP
       39 天前
    @morenacl 有没有具体的?
    shinelamla
        7
    shinelamla  
    OP
       39 天前
    @yule111222 像这种回答应该被推荐
    afxcn
        8
    afxcn  
       39 天前
    理清楚业务之间的关系应该不是件难的事情,难以下手往往是想太多,过度设计。
    securityCoding
        9
    securityCoding  
       39 天前
    找准两三个开源项目彻底吃透
    woodwhales
        10
    woodwhales  
       39 天前   ❤️ 1
    可以先看现已上线的系统功能需求,想想自己来设计会怎么设计库表及代码结构。然后看现有代码怎么实现的,存在不合理和合理的,一目了然。
    如果项目没有现成的已实现功能,可以列出自己的思路,找同事私下把把关,探讨一下。

    最后再配合楼上说的书籍加深理解,上来就看书,太理论,个人觉得对新人不友好。
    cstj0505
        11
    cstj0505  
       39 天前
    如果不是交易系统那种一点不能错的我反而不重视数据库设计,包括三范式也不遵循,关系数据库里大量用到 json 字符串,外键也不用.
    我觉得关系模型太繁琐了.
    NessajCN
        12
    NessajCN  
       39 天前
    https://www.mongodb.com/basics/database-architecture
    你问的太宽泛了,那我也只好宽泛地说根据需要选 Tier1~3 的架构
    至于具体选哪个 tier ,选好了之后怎么设计各个 layer ,得结合实际业务来
    shinelamla
        13
    shinelamla  
    OP
       39 天前
    @woodwhales 谢谢,挺好的建议
    nothingistrue
        14
    nothingistrue  
       39 天前   ❤️ 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 ,都不是单纯的技术设计,而是业务模型设计,产品/需求也是要参与的。如果产品/需求压根不管你啥模型,就盯着界面原型甚至效果图,还拒绝被模型引导,那你搞啥都不管用。
    pkoukk
        15
    pkoukk  
       39 天前
    我的理解是,数据和数据库是不同的,先理业务,理解你的数据流
    让数据走通整个流程,当你做完这一切的时候
    数据库只是最后保存的那一下,没什么难度了
    ZhuWenJian
        16
    ZhuWenJian  
       39 天前
    业务设计可以用状态归类。
    举个(前端)列子:实现一个具备多选、删除、全选的列表。
    页面按钮:返回、关闭、多选、全选、item 选择、删除。
    可以想想怎么设计合理。
    tianzx
        17
    tianzx  
       39 天前
    1 、设计不够合理,需要重来 :不需要设计的面面俱到,KISS 原则。就是先把一个模块最核心的东西设计出来。剩余的字段和相对资深的同事、架构师去讨论。
    2 、设计方案性能不够高或者后期维护麻烦 :1 、性能不够高 :这个是需要基础架构、业务架构的支持 。比如支持容器的扩缩容、读写分离、多级缓存、数据一致性 、分库分表 、是否需要反范式、索引是否合理、是否有数据倾斜和热点问题 2 、后期维护麻烦 :多想 1-2 步即可,比如需要多加一个字段、多支持一种业务形态。
    3 、另外的同事来做的话,会有更好的抽象,更合理的分层 :1 、多去问,如果你来设计会怎么想。和你的对比下,慢慢积累经验,业务架构不可能一簇而就。
    4 、唯一推荐:DDIA 。仔细读 3 遍
    piecezzz
        18
    piecezzz  
       39 天前
    不可能一步到位的,做个相对合理的 case 就行
    niubee1
        19
    niubee1  
       39 天前   ❤️ 7
    首先你需要先从建模开始入手,合理的模型才能高效的驱动业务,然后模型的持久化,数据库只是一种选择,文件,redis ,远程 API 也可以是持久化的一部分,把适合数据库的部分拿出来,再来说数据库表设计,数据库表和模型实体之间并不是严格的一比一的关系,虽然很多时候是一比一。一般来说基本原则还是遵循 3NF 范式,但是在某些地方,根据模型和业务的实际情况,需要做一个些反范式的设计,比如某些在 3NF 范式下 JOIN 深度超过 2 层的地方,用冗余字段降低到 2NF 范式,某些模型实体比较大的,根据访问频次,可能会切分成几个表,比如用户,用户的登陆信息和用户的属性就需要切分成两个表来存储,如果有一些统计字段,也会单独用一个表来存,因为登陆信息一旦插入,几乎很少修改,而属性则因为运营关系经常有需求会修改加字段,这个时候分开表就不容易被卡住。有用户的统计字段的话,因为经常性的更新统计信息,这个表比较热,所以更需要和其他几个表分开,这样保证了 1 ,模型的完整性 2 ,可扩展性 3 ,效率。做好设计后在纸上预跑一遍,不要依赖就急吼吼的拿起工具就建表,预跑一遍,把 SQL 写出来,然后才好规划索引,另外就是根据实际的业务来计算一下预计的容量,也是你系统的设计容量,比如有的表撑死了也就几百条一千吧条数据,那你除了主键外都没有必要建多余的索引。有的表预计记录条数超多,那么提前考虑好是否需要分表,分库。

    在真实世界里完美的设计是不存在的,因为其实完美的需求是不存在的,而好的设计和坏的设计的区别就在于如何取舍上,这个问题貌似没有哪本书能给你完美的答案。认识一个家伙特别喜欢买书,各类大作堆了一墙,但是能看完的,本就不多,看完了的,貌似也没啥用,搞数据库设计还是稀烂,经常扯到蛋(还是客户端的数据库)
    yueyuea
        20
    yueyuea  
       39 天前
    既然你已经明确了另外的同事来做的话,会有更好的抽象,更合理的分层,你就去学习,思考别人为什么会这么做,这个过程比无脑看书更有意义。
    eastjoehan
        21
    eastjoehan  
       39 天前 via Android
    先确定需求以及原型稿,然后根据需求确定功能结构图、信息结构图、业务流程图,照这些大概就能得出来一个概要设计了,然后跟产品或领导对齐细化,基本就可以开工了。 最重要是对齐,然后获取方案认可,不要闷头干。
    这就是最基本的流程,DDD 应该还太抽象了,如果你要看书那也有一本,最近我刚看的《软件设计:从专业到卓越》
    mccormickclariss
        22
    mccormickclariss  
       39 天前
    @niubee1 非常赞同!
    yuanmomo
        23
    yuanmomo  
       39 天前
    @yueyuea 这个是我喜欢的答案
    chf007
        24
    chf007  
       39 天前
    想得太多了
    shinelamla
        25
    shinelamla  
    OP
       39 天前
    最终发现没有很好的方法论,都是经验,做多了业务就慢慢触类旁通了。没有办法很好地总结,如果有,不一早就有人分享出来了?为什么这这方面的资料这么少?
    levelworm
        26
    levelworm  
       38 天前
    倒还不如问问看同事他是怎么做的。
    0x0208v0
        27
    0x0208v0  
       38 天前
    遇到过和你一样的情况。我选择看了很多 UML 的书,什么火球 UML 大象 UML ,又看了 DDD 各种书,又看买了极客时间的各种 DDD 的课程,浪费了很多很多时间,但是收获很少,每天都很纠结,写不出来代码,需求甚至延期。最后恍然大悟,脱离了目标谈抽象,永无止境,永远有更好的抽象。最近我发现思考“公司的业务是怎么跑起来的,钱是怎么赚的”,比技术好玩儿多了~ 如果楼主有更好的资料,求分享一波,我还是想知道怎么才能设计出更好的东西
    NewMoorj
        28
    NewMoorj  
       38 天前
    你比小白更加慎重,因为你见过一些坑,现在你在设计模型时会想办法避免这些坑。

    这就是个经验积累的过程,很正常。
    NewMoorj
        29
    NewMoorj  
       38 天前
    看到楼主说是求术的,很遗憾,没有捷径,任何写代码三五年的人,看自己第一年的代码,都会像看屎一样。
    panlatent
        30
    panlatent  
       38 天前 via Android
    DDD 当然值得借鉴,但更多的时候,从 0-1 设计会容易让项目陷入泥潭。我建议是在一种较成熟普遍,易于拓展和修改的设计上,先让代码落地,不断微调。大概可以叫渐进式设计 。

    理由就是我意识到自己的认知和能力有限,一下画不出一张大饼
    julyclyde
        31
    julyclyde  
       38 天前
    终于从技术回归科学了
    xianzhe
        32
    xianzhe  
       38 天前   ❤️ 1
    我觉得 27 楼的兄弟说的在理,设计出来好东西是不会凭空冒出来的,与其纠结怎样是好的,不如先快速试错,多迭代。世界的本质就是个草台班子,设计的再好抵不住人家早就把功能上线收客户钱了。
    zartouch
        33
    zartouch  
       38 天前
    这东西还是需要些经验的。

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

    一些关于架构,DDD 之类的书,我建议有点自己的思考再看,你现在看了只会有个似是而非的印象,踩过坑之前,很难深刻理解那么做的意义。当然一些基础的设计概念的书籍如 clean code ,设计模式,重构这类的我默认是肯定读过的,否则完全没有理论基础单纯靠经验那也是扯谈,容易走成野路子。
    x2ve
        34
    x2ve  
       36 天前 via iPhone
    过早优化杀死积极性
    lizy0329
        35
    lizy0329  
       36 天前
    大道至简,那些什么 DDD 只会坑死你不偿命,MVC 才是唯一真神
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2163 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 15:55 · PVG 23:55 · LAX 08:55 · JFK 11:55
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.