架构设计：抽离出“纯bot逻辑”？

hundun000

我已经写了一个直接用mirai-core作为独立应用启动的项目，准备尝试写它的mirai-console-plugin版本。逐步改造的时候发现，我的项目的架构可能会变成下图所示。

我的问题是：

“抽离出一个纯bot逻辑模块，其可以同时作为独立应用或者作为插件”是一个好的设计思路吗？
纯bot逻辑模块使用java，假设图中的适配器和BasePlugin使用kotlin，这样是不是在实践“建议开发插件时混用java和kotlin”？
基于以上两点，这个设计方案值得作为某种template推广吗？

Nambers

我的项目也同时做了mirai-core和mirai-console版本，其实里面的绝大部分代码都是一样的，比如subscribe事件，我觉得实际上是可以提出的，我一直也打算提出成单独的jar文件，然后在两个版本依赖，就不用同时维护两个地方了，不过现在还没做到

hundun000

@nambers 在架构设计：抽离出“纯bot逻辑”？中说：

我一直也打算提出成单独的jar文件
4. 动态引用需要每个方法都写一次，计划暂时变更为用gradle引入(compile)本地jar包

我现在是botLogic一个子项目，作为独立应用的Loader一个子项目，作为Plugin用一个子项目。然后通过gradle 子项目间依赖来使用，开发期间会动态依赖botLogic源码，改了botLogic不需要重新打成jar。

dependencies {
implementation project(":botLogic");

不过这样弄出了gradle子项目关系，就不能照抄mirai教程的gradle写法了，现在我的Plugin子项目刚起步，我还不确定它的mirai相关依赖配置正确没有。

Nambers

@hundun000 确实喔可以用子项目，我之前没想到，我待会去试一下

Him188

实际上可以考虑只支持 mirai-console，因为 mirai-console 可以像 core 一样嵌入使用？

hundun000

@him188

实际上可以考虑只支持 mirai-console，因为 mirai-console 可以像 core 一样嵌入使用？

我想的是《Mirai生态图》里的“你编写的机器人程序”和“你编写的插件”之间怎么管理。所以保持原图“你编写的机器人程序”只依赖core不依赖console。

把我的方案放进生态图应该是这样：

hundun000

研究了几天，增加了对插件设计粒度的理解。发现我的独立应用不适合转为插件……至少是不适合转为“一个插件”。

假设需求是：第一个bot账号加入群A，需要功能a和功能b；第二个bot账号加入群B，需要功能b和功能c；

如果一开始就按插件来实现这个需求，较好的方案应该是：开发出插件a、插件b、插件c。把插件a和插件b放入第一个mirai-console然后登陆第一个bot账号。把插件b和插件c放入第二个mirai-console然后登陆第二个bot账号。

然而我为独立应用写的“纯bot逻辑”是：写一个同时提供a、b、c功能的服务，和一个可配置的调度器，配成第一个bot账号只能使用其中的a、b功能，第二个bot账号只能使用其中的b、c功能。

此时再试图把“纯bot逻辑”包装成插件，就会觉得这个同时提供a、b、c功能的插件“过重”，混杂了没有什么关系的功能a、b，还需要学习配置调度器。这不是一个合适的插件。

Mill413

@hundun000 我的想法是给每个bot写个配置文件，配置他要用的功能名称，abc三种功能分别写在一个类中，然后启动bot的时候根据配置文件加载相应的类。我自己是这么管理多个功能的：每一个功能写成一个类，每个功能类有个属性switch，我可以给bot发指令改变这个switch值，然后在这个功能类中的subscribe里都套上一层if（switch）

lc6a

可以看看我的拙作：

https://mirai.mamoe.net/topic/317/springmirai-集成mirai-console的可自定义可扩展kotlin机器人开发框架-启动器

不过目前结构也存在一些问题，有重构的打算。
如果你也是基于springboot开发，欢迎交流经验！
我认为：

可以对设计进行分层次抽象，例如分为jvm全局、插件级别、指令级别3层。
定义过滤器模块，可以编写一个个过滤器，各过滤器可以设计为独立平等关系，也可设置为层级关系（例如伪代码：过滤器AtMeFilter(true)的前提是过滤器EventFilter(MessageEvent::class)），但过滤器最好不直接跟机器人功能耦合，提供默认绑定关系即可，应该让用户能够运行时动态绑定、解绑过滤器与功能（点名批评自己的框架，使用注解将过滤器和功能静态绑定，无法动态更改）。
定义机器人功能模块，仅仅包含机器人逻辑，数据来源由框架提供（参数注入），消息发送也抽象隔离开。
AOP，面向切面编程能够方便的在机器人逻辑前后添加通用逻辑，例如返回值如何作为消息发送回去。
至于同时维护基于core和mirai-console的两个版本，我觉得Him188大佬说得对，直接将mirai-console作为依赖添加到项目即可，项目提供main和plugin两个入口，我的SpringMirai项目就是这样做的。

hundun000

@mill413
嗯，我差不多也是这样实现了。主要考虑是我的功能a、b其实分别指的是一个大功能的集合。具体来说，a是明日方舟游戏助手，包含数个明日方舟相关的子功能；b是舰队收藏游戏助手，包含数个舰队收藏相关的子功能；用户或社区开发者，应该大多数都是只希望使用/开发其中一个游戏的大功能吧？即使说明了可以通过配置不启用另一个游戏的大功能。感觉还是不如分开成两个插件。

hundun000

@lc6a 谢谢，我晚点研究一下。
我之前试过mirai+springboot，独立启动版SpringBootApplication作为main会弄，不过不够精通springboot，不会弄作为插件时如何正确加载SpringContext等，最后就忍痛移除了Springboot。

不过即使移除了Springboot，但是我的框架还是保留了AOP和IOC的风格，再改回Springboot也可以考虑。

hundun000

@hundun000 在架构设计：抽离出“纯bot逻辑”？中说：

研究了几天，增加了对插件设计粒度的理解。发现我的独立应用不适合转为插件……至少是不适合转为“一个插件”。

虽然嘴上说着不合适，还是试着把所有功能打成一个插件并成功运行了。姑且先用插件挂着，后续考虑怎么改。