我正在开展一个项目，这是我们公司首次涉足领域驱动开发。
我们的Web API最初只提供了CRUD操作和项目暴露的OData控制器，但我不确定这是否仍然是个好主意。
OData是暴露非CRUD API的好方法吗？
更多信息： 最初我们的web api基本上暴露了CRUD功能。要创建新用户，您只需创建一个并将其发布到服务。例如，要更改地址，您将获得用户实体的副本，进行更改，然后执行更新操作。基本的OData东西。
除了提供查询支持外，OData还以易于使用的方式公开服务，因此可以将其作为服务引用添加到其他项目中，并通过代理进行访问。
由于我们已经转向DDD方法，因此情况发生了重大变化。我们的Web API现在只是一个通向许多独立子域服务的网关。我们不再提供CRUD操作或直接访问实体，而是进行服务调用以操纵实体。消费者必须生成CreateUserBindingModel并将其发送到User / Create服务并让服务生成实体，而不是通过Put请求创建将其发送到User服务的User实体。更改地址是通过ChangeAddress（ChangeAddressBindingModel模型）方法完成的，而不仅仅是更新整个对象。查询更有针对性，很少返回整个域对象。
当我们不再提供CRUD操作时，继续使用OData作为我们的Web API的基础是一个坏主意吗？有没有其他方法可以用OData的方式公开我们的服务细节？我知道WCF服务提供了类似的功能，但我的印象是它与CRUD的关系比OData更多。
答案 0 :(得分：2)
OData是面向数据的API规范，它是反DDD的。尽管它可以满足您实现REST API的所有要求，但是最好用于数据处理API。我想您已经知道使用OData就像通过HTTP操作数据库一样。如果您使用的是DDD，则应该完全忘记OData。
答案 1 :(得分：0)
在OData中，操作和功能是一种添加服务器端行为的方法，这些行为不容易定义为对实体的CRUD操作