我在上一家的时候，软件的代码结构是这样的，主界面只实现一个框架的功能，具体的业务细节通过反射加载其他的dll完成。

我在上一家的时候，软件的代码结构是这样的，主界面只实现一个框架的功能，具体的业务细节通过反射加载其他的dll完成。

我在不停的堆积功能之后，我也遇到了这个问题，如果所有的逻辑都沉淀在主窗口中，那么这个逻辑最终会扩大到无法维护。

所以我给的解决方案是，不停的将主窗口中成片的逻辑拆分出来，比如一些通用的Util方法，热键，主题，语言，等等这些拆分到下层的dll 中。在主程序中加载这些小的dll。

下层的dll 是干净了，不存在相互调用的依赖，只需要调用下层的dll 即可。

但是加载逻辑依旧要在主程序中实现，也就是主程序的复杂度并没有降低，只是优化了逻辑，让分散的代码，成块状管理。在复杂度不变的情况下，可以实现更复杂的业务逻辑。

这个样子，换汤不换药，不解决问题，只是推迟问题的爆发。

前段时间，灵感突现，给代码进行了更进一步的分类，定义了那些模块使用反射的实现方案是更好的选择。

复杂度进一步降低了。

主程序只负责实现某个模块的元数据转换成对映的功能。复杂度就交给了具体的实现模块。复杂度就不会随着项目的扩展叠加了，变成了多个小的复杂度。

再进一步，如果当主程序和某个具体的实现模块不再关联的时候，这个模块就可以剥离出项目，成为一个单独的插件，让程序在运行的时候先去加载插件，然后再去创建模块。

如果再进一步，把业务逻辑直接从主窗口中剥离，让主程序只去实现UI层的逻辑，业务逻辑就可以剥离出来，让主窗口只剩下一个加载器的功能。

我在上一家公司的时候，实现的逻辑就是在这一层，不过不完整，这也是为什么开发非常费劲的原因，缺乏了基础库，缺乏了大量的基础模块，比如启动，菜单，配置，状态。 只有操作和视图这两个模块是存在的，如果想要操作其他的模块，因为没有中间层，所以会浪费大量的时间。

原来不是什么巧合，正是因为我本能的捕捉到了这些缺乏，并且进行了补天式的修改，后续才是这个ya，可惜了。

在之后呢，就不是一个程序的事情了，这里是传统程序和互联网程序的分歧点。

为了更好的分离，降低每个模块之间的复杂度，把前台逻辑和后台逻辑做一个拆分。 C++ 和 C# 的协同，前台和后端的协同都是这个道理。

如果不同的系统之间，采取Json来进行通讯，那么对于整体的逻辑就把显示和处理分离了。 前台的逻辑只需要做到接收到数据并且显示。 后台的逻辑只需要实现操作处理数据到发送。

如果一旦拆分到这个程序，那么对于后端而言，一切操作最后都是在某个接口上发送数据。不同的接口之间可以拆出微服务实现。

大量的前台工作都是趋同的，前台工程化也是理所当然了。

单体程序的另一个发展方向是流程化。

在之后，因为系统消息之间的沟通，有了统一实现，那么流程化就成为了可以操作的事情。

这是低代码的起点。

蓝图的实现。