（这是在Java项目中）
我正在使用一个与关系数据库并行的搜索引擎。感兴趣的主要对象是"列表"。它在合成样式结构中有大约5个其他实体。一个是位置，另一个是复杂的时间和日期定义。
根据我的经验和研究，在Solr、Lucene、Elastic SEarch上的搜索速度比添加全文和地理索引的任何数据库都快。所以，这就是为什么我希望对数据库中的数据使用搜索引擎。此外，搜索引擎将包含比数据库更细粒度的时间条目，与形式相比更具体。
因此，参考设计模式：目标是从API对实体上的数据库内容以及搜索引擎索引中实例化的所有时间和地理排列进行CRUD。
我已经和一位合伙人讨论过了，我相信他说的是对的为了保持低耦合，"Listing"类（同样是数据中数据层次结构的顶部）不应该知道搜索引擎，也不应该添加在搜索引擎上进行搜索的静态函数。他表示，"责任链"设计模式可能是允许API的CRUD对数据库和搜索引擎内容采取行动的适当方式。我认为这是不对的。
我一直在看http://sourcemaking.com/design_patterns我认为立面图案，http://sourcemaking.com/design_patterns/facade，可能是最好的。但我想听听其他意见。
提前谢谢。
PS。我正在开发一个osem层(http://en.wikipedia.org/wiki/Compass_Project)能够注入春季国际奥委会。该层是为ElasticSearch定制的。到目前为止，它还不支持事务或外键（可能永远不会支持）。但它稍后会有注释挂钩来开发这些挂钩。你可能想看看。它在https://github.com/kwince/osemManager。目前有两个分支正在进行中。我将在下周决定合并哪一家。
立面模式更适合将一些复杂的子系统隐藏在相对简单的界面后面。
据我所知，你有两个不同的系统，你想向这两个系统发送相同的请求。你需要知道这两个系统之间的关系：
- 如果一个系统比另一个系统有某种形式的偏好，你会使用责任链：你会发送一个请求，如果第一个系统能够处理，你会得到结果，如果不能，请求会转到链中的下一个系统，以此类推
- 如果有某种形式的结果通过另一个系统的结果来推断或增强一个系统，你可以使用Decorator，所以请求首先到达"外部"系统，它调用"内部"系统，获得一些结果，然后用自己的数据装饰它们，并返回装饰的结果
- 如果你只想并行查询两个独立的系统，那么使用"just do it"模式=）使用框架中的一些parralel原语，发送两个请求，等待两个结果，将它们提交给合并函数
希望这能有所帮助。