我正在尝试在 Symfony 2 中为 ReST 客户端建立一个最佳实践模式，因为这对我们公司来说是一项非常常见的工作，我们在前端有 Symfony 应用程序，通过 HTTP/ReST 与基于 Java 的后端通信。
我的想法是，这些服务在DDD中为特定域填充“存储库”角色。根据 Doctrine 指定的约定，这些将进入返回 Entity 对象的 Repository 类。
我认为同样的约定也可以在这里工作，ReST 客户端使用像 Guzzle 这样的库或直接 Curl 来实现一个 Repository 类，不管如何，然后那里的代码进行从 XML 或 JSON 到实体的基本转换供上游开发人员操作的对象。这与其他 Symfony 2 用例中的模式一致，并且从 DDD 的角度来看是有意义的。
有没有人看到这个问题或更好的方法？
以下是在 symfony2 中处理 REST API 开发的最佳文章：
http ://welcometothebundle.com/symfony2-rest-api-the-best-2013-way/
FOSRestBundle和NelmioApiDocBundle是快速休息 api 开发的不错选择。您可以访问官方文档了解如何安装、配置和使用它。
我喜欢你概述的方法。您可以将您的存储库视为一个反腐败层，它将您的 ReST 客户端代码与您的域模型隔离开来。
如果您正确考虑了所有涉及的缓存层，则此方法有效，以确保您的存储库不会缓存超出您检索的 REST 对象的 TTL（由 etags 或过期标头或您的 REST 服务器使用的任何内容设置）。
绝对 Repository 是正确的层，尽管也许在 Symfony 中你想更上一层并将其视为实体管理器，因为它允许你抽象该层的操作，例如持久化、删除和刷新。
如果你打算这样使用它们，我认为你在滥用 Symfony 中的存储库。最好在您的存储库中使用 setter 和 getter，并在服务中使用 guzzle/curl 进行处理。
控制器/命令 -> 服务方法 -> 存储库
然后，根据您的需要，您可以编写一个 Command/Controller 来根据您的需要公开服务中的方法。