在这种情况下我应该使用哪种设计模式：
我想实现更多技术，我不想修改核心，我想只添加模块到系统。例如，添加电报消息，Twitter消息或其他电子邮件提供商。
有什么建议？
对我来说，似乎PUB-SUB模型或观察者模式是最好的，以注册到发布者的订户形式的扩展很好地工作，因为订阅者可以从核心通知服务中抽象出他们自己的实现细节。
策略模式：
定义一系列算法（您的通知类型），封装每个算法（每种类型的通知），并使它们可互换（使用通用抽象）。策略允许算法独立于使用它的客户端。捕获接口中的抽象，将实现细节隐藏在派生类中。
每次要添加不同类型的通知时，您都会添加新策略（Twitter，Telegram，ecc）
对于通知系统，我建议您使用Observer模式。您收到的消息应该在您的Subject内。主体应允许任何数量的Observers附加。收到消息后，主题应通知所有观察者。然后Observers可以从主题中读取状态/消息并对其进行操作。我对你的用例并不十分清楚。但这可以做到这一点。
观察者 - 可观察的模式适合你。如果你使用在期货中构建的任何框架（java中的spring） - 比如事件监听器和发布者 - 这确实减少了你的实现负担。
我希望你已经在使用框架 - 所以研究事件监听器+发布者。它真的解决了你的问题..不仅增强了对多个供应商的支持..它还支持 - 单一 - 多线程，更改少。
根据您的问题陈述，将涉及两种不同类型的设计模式：
1）策略模式：它将根据电子邮件，推送，whatsapp等上下文定义通知策略。
3）观察者模式：它将执行发布者和订阅者操作将松散耦合的行为。它会自动通知订阅者。
您还可以将RabbitMq集成到某个位置以便按时排队并按时推送消息。