关于 Java 中 maven 多模块项目的疑问 - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
woyao396
V2EX    Java

关于 Java 中 maven 多模块项目的疑问

  •  
  •   woyao396 2021-02-20 16:05:21 +08:00 4304 次点击
    这是一个创建于 1723 天前的主题,其中的信息可能已经有所发展或是发生改变。

    1 、maven 多模块项目为什么有人按服务分 又有人按代码层分? 哪一种是最佳实践

    按服务分:

    • xxx-user
    • xxx-order
    • xxx-search

    按层分:

    • xxx-web
    • xxx-service
    • xxx-dao

    2 、假如按第一种服务分,如 github 上高达 46.4k star 的商城项目 https://github.com/macrozheng/mall

    子模块被打包后、不同 jar 包中 中大量重复的 jar 包被引入( spring 的 jar 和 子模块的 jar 如 common ) 这样打出的包最后不是很大?这难道合理吗? 难道不是一个 jar 被多个项目引用吗?

    3 、按层分多模块的意义到底在哪?网上找了很多好处说 感觉没有说服力。

    4 、父项目把所有子项目都需的依赖放到dependencyManagement里合适吗?

    15 条回复    2021-03-31 19:36:23 +08:00
    iyaozhen
        1
    iyaozhen  
       2021-02-20 16:19:22 +08:00
    我们是这样的
    1. 按模块 /服务分,甚至某些子模块是要独立部署的服务
    2. 这很正常呀 mall-search 、mall-admin 就是两个不同的服务(独立运行的 tomcat 实例、或者 docker ),肯定有重复的
    3. 这种没太见过
    4. parent pom 依赖有两种,dependencies 表示都有的依赖,这样子 pom 就不用重复定义了。dependencyManagement 是 parent 声明了版本,子 pom 只需要配置 groupId 、artifactId
    chendy
        2
    chendy  
       2021-02-20 16:24:38 +08:00
    1. 按模块分
    2. 上百 M 依赖+几百 K 自己的 class 是 java 项目常态,有需要做点镜像分层之类的优化就行
    3. 纯没事找事,加一个接口直接打穿好几个模块一起改,图个啥
    4. 合适
    caixiaomao
        3
    caixiaomao  
       2021-02-20 16:27:48 +08:00
    习惯按模块分 清晰一点
    chippai
        4
    chippai  
       2021-02-20 16:35:02 +08:00
    user 、order 是俩个项目了
    单个项目是会分 api 、service 、starter
    - user-api (对外提供 RPC)、
    - user-serivce (服务实现 Provider)、
    - user-starter (springboot 启动层(各种配置信息和 profile))
    xuanbg
        5
    xuanbg  
       2021-02-20 16:35:45 +08:00
    最讨厌多模块项目了……

    搞不搞微服务,都是一个模块一个项目。
    JadeLove
        6
    JadeLove  
       2021-02-20 16:39:39 +08:00
    我一直很好奇选择多模块的原因是什么。。
    zhady009
        7
    zhady009  
       2021-02-20 16:43:26 +08:00
    我们这边是打包把第三方的 jar 和源码分开
    云盘上面先把第三方的 jar 按照集群应用放上去
    启动参数 classpath 指定多一个对应的路径就好了 除非有第三方依赖更改才要更新
    sss666
        8
    sss666  
       2021-02-20 16:55:53 +08:00
    @urzz 代码复用,面向 jar 包编程
    zliea
        9
    zliea  
       2021-02-20 17:04:12 +08:00
    1. 按照服务分,多模块是为了多个服务共享某些相同的代码。
    2. 开发阶段 maven 是一个 jar 被多个项目引用;但打包的时候如果不打包这些依赖,你需要保证在其他机器部署的时候,classpath 下需要有你用的 jar,而且需要保证版本不能和其他工程冲突。
    3. 多模块其实就是为了共享相同的代码,假设一个商城,有商品系统、订单系统、支付系统,很多代码可以共享;
    其实我觉得单独打包 jar+版本管理,才是比较好的选择。
    4. 合适,首先子项目不需要些 version,首先可以保证版本一直,而且在版本升级(有漏洞的时候)可以保证大家都升上来了。
    iseki
        10
    iseki  
       2021-02-20 19:05:43 +08:00
    为什么打包全达成 fat-jar 。。。实际上你看看每个独立运行的 fat-jar 并不会重复包含 jar 作为 lib,在实际中这也是没必要的(除非你通过类加载器(你不能重复加载同一个类))
    hantsy
        11
    hantsy  
       2021-02-21 09:55:13 +08:00
    分得太细,管理也是一样问题。曾经一个项目分的 Maven Module 多达 40 个。

    现在的经验是,除非每个 Module 是单独部署,否则不分。

    不同的(单独部署的) Moudle 之间有些类需要共享,抽出一个共享的 Module,如一些简单的 Dtos (用于统一 Caller 与 Callee 之间的格式)等,永远不要共享数据库等。
    hantsy
        12
    hantsy  
       2021-02-21 10:06:08 +08:00
    在多模块 Parent/Child 依赖处理时,将所有的项目的依赖定义在 dependencyManagement 中,统一管理项目所有依赖,最顶层的 parent module 在项目中作为一个 BOM 存在,不要将添加任何 dependencies,dependencies 下所有的依赖声明会污染所有 Module 。

    对于一个逻辑单元下 Module,如下结构,order-parent 存在父子结构,根据情况可以在父 pom 考虑添加 dependencies 。

    parent
    --
    --
    --order-parent
    --- order-api
    --- order-model
    Joker123456789
        13
    Joker123456789  
       2021-02-22 11:32:32 +08:00
    按服务分的项目 一般是微服务项目,你可以展开看看,每个服务里面估计都分了 层的,也就是 web,service 这些,不过不一定是用模块来分层,也有用 包 分层的。

    按层分的 基本是单体项目,业务模块不多,并发量不大,但是代码有点多,就干脆用模块来分层。
    SkyLine7
        14
    SkyLine7  
       2021-02-23 09:42:02 +08:00
    我们两种 2 种结合用的,服务分子 pom,里面再按三层结构分
    iseki
        15
    iseki  
       2021-03-31 19:36:23 +08:00 via Android
    @urzz 有时候不得不多模块是为了方便跑 apt 这种东西
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     1109 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 27ms UTC 17:25 PVG 01:25 LAX 09:25 JFK 12:25
    Do have faith in what you're doing.
    ubao msn snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86