是否考虑将halo不同的功能拆分成模块化？

[NGLSL]

我确定我已经查看了 (标注[ ]为[x])

• Halo 使用文档
• Halo 论坛
• Github Wiki 常见问题
• 其他 Issues

---

我要申请 (标注[ ]为[x])

• BUG 反馈
• 添加新的特性或者功能
• 请求技术支持

我发现halo的代码好像不少了，有很多功能很多包。有些功能可能暂时用不上。是否考虑将其拆分成不同的模块，也好方便扩展，要新增什么功能添加什么模块即可。就像使用的依赖一样，我不需要这个功能，那就不添加这个依赖，新增什么功能就在对应的模块上开发功能即可。

其二，我不清楚gradle是否能像maven一样，设置parent，统一管理依赖的版本。这样拆分成模块化之后，也不会出现版本依赖混乱的问题。

[ruibaby]

@NGLSL 我也是这么想的，不过难度太大。

[ruibaby]

所以我们现在在研究插件系统，如果可以，那么你所说的那样都可以实现。

[NGLSL]

@NGLSL 我也是这么想的，不过难度太大。

或许不用拆分的那么细致，基础功能保留在固定的模块。像一些core、model、plugin、security这些我感觉是可以拆分出来。不过工作量还是很大的，可以说是一次重构了。

当然，我只是有这么一个想法，是考虑到方便更多的开发者进行开发或者维护。

我今天想看看代码，看看其中是否有优化的地方，却不知道该去怎么下手。

[ruibaby]

@NGLSL 我也是这么想的，不过难度太大。

或许不用拆分的那么细致，基础功能保留在固定的模块。像一些core、model、plugin、security这些我感觉是可以拆分出来。不过工作量还是很大的，可以说是一次重构了。

当然，我只是有这么一个想法，是考虑到方便更多的开发者进行开发或者维护。

我今天想看看代码，看看其中是否有优化的地方，却不知道该去怎么下手。

可是这样对小白不友好啊。

[ruibaby]

没有做到开箱即用那一步的话，不会拆开。

[NGLSL]

@NGLSL 我也是这么想的，不过难度太大。

或许不用拆分的那么细致，基础功能保留在固定的模块。像一些core、model、plugin、security这些我感觉是可以拆分出来。不过工作量还是很大的，可以说是一次重构了。
当然，我只是有这么一个想法，是考虑到方便更多的开发者进行开发或者维护。
我今天想看看代码，看看其中是否有优化的地方，却不知道该去怎么下手。

可是这样对小白不友好啊。

打的包包含了基础功能，其他的功能就是Plugin，要使用直接添加进去即可。

> halo
 > common-core
 > common-model
 > common-util
 > admin
  > 包含了基础功能
 > front-end
   > 包含了基础功能
 > plugin
   > background-plugin
   > black-list-plugin
   > ...

[ruibaby]

@NGLSL 那就是我说的插件的概念了。

[NGLSL]

没有做到开箱即用那一步的话，不会拆开。

把功能拆分后，并不会影响到开箱即用的问题

[NGLSL]

@NGLSL 那就是我说的插件的概念了。

差不多是这么个意思，可以考虑一下

[NGLSL]

@NGLSL 那就是我说的插件的概念了。

无论是开发起来还是用起来，都会灵活很多，有助于开发者快速了解项目

[ruibaby]

很早就有这些想法了，也做了一些常识，效果都不是很理想。#125

你有好的想法可以试试。

[NGLSL]

很早就有这些想法了，也做了一些常识，效果都不是很理想。#125

你有好的想法可以试试。

of course！

但具体细节和注意事项，还需要讨论。

[ruibaby]

很早就有这些想法了，也做了一些常识，效果都不是很理想。#125
你有好的想法可以试试。

of course！

但具体细节和注意事项，还需要讨论。

Flarum 其实就是这种模式，所有功能点都是一个插件。

[NGLSL]

很早就有这些想法了，也做了一些常识，效果都不是很理想。#125
你有好的想法可以试试。

of course！
但具体细节和注意事项，还需要讨论。

Flarum 其实就是这种模式，所有功能点都是一个插件。

这种方式够灵活！项目大了就要拆分，我在工作中有多次从零开始的项目和重构的经验。也许我可以写一篇拆分项目的文章，分享出来大家可以提出一些自己的意见与建议。

共同讨论halo的plugin功能该怎么去实现会更灵活。

[ruibaby]

@NGLSL 嗯 好的。

[JohnNiang]

我回答一下第二个问题：

Gradle 也是支持模块化管理的。重要的配置在于 settings.gradle，不过多模块搞起来总觉的怪怪的，不如微服务来得舒坦。

[NGLSL]

我回答一下第二个问题：

Gradle 也是支持模块化管理的。重要的配置在于 settings.gradle，不过多模块搞起来总觉的怪怪的，不如微服务来得舒坦。

我拆分项目的经验，就是因为来自于微服务。但，把halo弄成微服务，就有些成本过高了，不如单体应用好——拆分后的单体应用，我更喜欢叫这种为模块化。

[JohnNiang]

等 halo 这次版本发布且稳定了之后，可以考虑模块化 @ruibaby @NGLSL 。

[NGLSL]

等 halo 这次版本发布且稳定了之后，可以考虑模块化 @ruibaby @NGLSL 。

👍

[JohnNiang]

需要 @NGLSL 您的支持 ：P

[NGLSL]

需要 @NGLSL 您的支持 ：P

能帮助开发,当然最好啦:D

[ruibaby]

需要 @NGLSL 您的支持 ：P

[NGLSL]

需要 @NGLSL 您的支持 ：P

当然乐意,参与开源项目,有助于美化我的RESUME!😁

[NGLSL]

@ruibaby @JohnNiang

从一开始的小项目逐渐变成了大项目而得臃肿，怎么办？讨论一下我的想法。

这是我写的一篇文章，看看有没有帮助？

[songlongkuan]

我之前也做过一些重构方面的工作

core （核心）
     core-app  //公共Controller
     core-common 
              base   //一些base类
              bridge //以供各个服务之间调用
              cache  //缓存
             ......
     core-service  //公共接口实现
     .....
           
//子模块示例   还可以再加 file子模块  comment子模块 等等
user
    每个模块下有四个moudle
     app  //controller
     common //user下的 model service接口 ....
     service  //user模块自己的实现类
     bride2core //user 向其他服务所提供的调用实现

[ruibaby]

@pencilso 我们也可以这么做，主要是用户端，如何让用户方便的安装和卸载。也就是可插拔设计。

[songlongkuan]

@ruibaby 可插拔就比较困难了，在Android的领域中是有一个插件化的概念，也比较成熟，它可以加载apk包然后run。
如果只是加载jar包的话 还是有方案的 用Classload加载jar，但是涉及到配置文件等等就比较复杂了。
后续我也查一些文献看看。

[NGLSL]

@ruibaby 可插拔就比较困难了，在Android的领域中是有一个插件化的概念，也比较成熟，它可以加载apk包然后run。
如果只是加载jar包的话 还是有方案的 用Classload加载jar，但是涉及到配置文件等等就比较复杂了。
后续我也查一些文献看看。

挺好，把halo实现成热拔插就爽了

[JohnNiang]

不知道各位现在模块化得如何了 ：P

[NGLSL]

不知道各位现在模块化得如何了 ：P

还没开动

[feitian124]

我这方面有经验，也注意到这个问题：
1 模块化
2 插件化
我先试试模块化

[JohnNiang]

我这方面有经验，也注意到这个问题：
1 模块化
2 插件化
我先试试模块化

很期待您的参与。

[nancheung]

很高兴可以看到一个这样的issue，早在这个项目只有300 star的时候，我就已经关注到它了，那个时候的halo项目极为简单，并不复杂。后来我就只把它当做一个好用的产品来用了。已经很久没有关心它的代码了。
但是我现在看到你们说项目逻辑极为复杂，那确实可以拆分为多模块。
我对模块封装和边界划分、以及利用spring的注解式条件化自动配置特性，把公共组件封装为可插拔式组件，都较有经验。但我只熟悉maven的依赖管理，所以这方面如果有需要我可以提供一些帮助。
之所以没有选择直接动手修改+pr，是因为对于组件的抽离封装是需要对halo的整体产品和业务有很深的理解，这种事，只能由halo的核心开发者居中协调才能保证重构后的合理性和扩展性。

甚至我认为halo不仅仅只做一个好产品，也可以是一个好的学习项目。使用行业内较新的技术，架构设计和代码编写足够优秀。甚至拆分为微服务这种复杂架构。
对于开发者：代码复杂且严谨，令人震撼，具有学习价值。而且因为是基于一个“好产品”的前提，代码和业务逻辑是经过无数人检验的，拥有完整的产品逻辑和流程，比如现在，虽然是一个单体项目，也并不复杂，但还是比市面上绝大部分入门教学式的demo产品优秀很多。

对于用户：将代码细节全部隐藏，能像现在这样，使用docker或者compose一键部署项目，将用户流程最简化。

~当然我一年前加入qq群的时候，群主就说了以产品为重，毕竟用户说好才算好嘛！我也赞同，产品力是第一驱动力！

[JohnNiang]

@nancheung97

非常感谢如此诚挚的回复，感谢一直以来的支持！

我们会努力向好的方向靠近，不断地优化。

[ruibaby]

@nancheung97

感谢你的评价，也期待你的参与。Halo 还有很长的路要走。