按业务拆分模块的疑惑

本贴最后更新于 1779 天前,其中的信息可能已经东海扬尘

前情概要

打算做一个 Java admin 快速开发框架;将常用的库、权限管理、用户管理...啥的集成,方便平时做点小项目。

项目结构

  • xinyue-platform 是 parent 项目,类型是 pom
  • xinyue-admin 是 Web 项目,用来最后打包运行的后台管理服务
  • xinyue-business 是所有的业务逻辑模块,模块内按照业务分包(业务包内分层),如图:
  • xinyue-core 是项目核心模块,包含一些 base 基类等等
  • xinyue-common 作为公共模块,放一些常量、工具类、枚举啥的
  • xinyue-generator/xinyue-task 暂时可以忽略,还没设计 😂

依赖关系

  • xinyue-admin 依赖 xinyue-business
  • xinyue-business 依赖 xinyue-core
  • xinyue-core 依赖 xinyue-common

设计初衷

因为未来比如用这个 platform 做电商项目,可能还需要对外提供 xinyue-api-h5/xinyue-api-appliet 一类的服务;所以希望可以将业务逻辑下沉到单独的模块,可以供 admin(后台管理系统)和各个终端 API 调用

这也是为什么 xinyue-business 模块内部,分层的时候只有 entity、repository、service 层的原因了,因为具体这些服务对外提供的接口;可能路径不同,也可能需要在不同的 Web 层在进行一些业务逻辑

所以 controller 层被单独拿到了 xinyue-admin 模块(也有可能是未来的 xinyue-api-xxx 模块),如图:

疑问

目前的设计存在哪些问题?

  • 由于自己还在上学,没接触过过大型项目,都是在 Google 和开源项目中学习了一些思路
  • 自己根据自己的业务特点设计了如上的结构,不知道是否标准,或者说存在着哪些问题呢
  • 之前参考的项目多是按业务模块划分,模块内 entity、repository、service、controller 分层,有些疑惑:
    • 比如分为 user 模块和 order 模块,不采用微服务,那么最终还是要打包到某个 Web 服务中发布运行的
    • 可是如果 order 模块某些逻辑需要依赖 user 模块,直接在 order.pom 中添加 user 的依赖会不会有点怪怪的
    • 并且,这样岂不是 maven 会有重复依赖的问题,比如 order 和 user 都有 springBoot-starer-web/data--jpa 的依赖,order 再依赖 user,那么 springBoot-starer-web/data--jpa 不就重复依赖了么?

business 按业务分包是否可以直接拆分为 xxx 模块

  • 有的时候在想,目前的 business 内按照业务分包,会不会导致未来各个业务包之间边界越来越模糊的问题(同在一个模块,可以直接互相调用其他包)
    • 比如同上的情况;order 的某些逻辑依赖 user ,那么可以直接在 orderService 中调用 user 提供的 service/repository,没有任何壁垒
    • 那么各个业务包是否丧失了高内聚、低耦合的核心
  • 若拆分为各个业务模块,又是否能解决这些问题

项目中的依赖关系如何管理

参考、分析了 4、5 个 GitHub 上高分的类似快速开发平台,发现这些项目被 Idea 的 Maven 提示 omitted for duplicate,其实也是我第一个问题里面提到的重复以来的问题;看提示 maven 应该会自动处理,主要就是心里面有点想不通,这样会不会有隐患

结语

希望各位可以给一些参考意见,小弟不胜感激

  • 架构

    我们平时所说的“架构”主要是指软件架构,这是有关软件整体结构与组件的抽象描述,用于指导软件系统各个方面的设计。另外还有“业务架构”、“网络架构”、“硬件架构”等细分领域。

    142 引用 • 442 回帖
  • Q&A

    提问之前请先看《提问的智慧》,好的问题比好的答案更有价值。

    8449 引用 • 38491 回帖 • 155 关注

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...
  • 88250

    项目结构没有所谓的标准,都是在使用过程中逐步演进的。我的建议是初期不要拆分模块,解决简单的业务就用简单的方案,基本分下包就好了。

    软件工程应以实用为主,软件过程也是随业务一起演化。框架作为软件的半成品,主要考虑的是基础功能,业界最佳实践仅作为参考,并不是一定要照搬的。

    避免过度设计,过早优化,简单的方案往往是最好的。

    2 回复
  • 其他回帖
  • xinyue 1 评论
    作者

    另外,这两天做前端(使用 Vue)遇到一个问题;黑客派使用 iOS Safari 添加到桌面后,可以隐藏浏览器的工具栏;我也参考黑客派设置了 apple-mobile-web-app-capable 为 yes;总是不生效,搞了一天也没找到原因,不知为何呢?

    1 回复
    要添加 PWA 吧
    Vanessa
  • xinyue 1 评论
    作者

    已解决,感谢 @88250 @Vanessa ღ( ´・ᴗ・` )比心

    客气了
    Vanessa
  • xinyue
    作者

    是的呢,自己重新规划了一个粗粒度的拆分;确实是自己考虑的太多了 谢谢大大

  • 查看全部回帖