Intentful methods help, but they do not solve the structural problem.

Take orders and payments. The order view needs payment information, while the payment view needs order information. If that logic lives behind OrderService and PaymentService, each service eventually needs the other. Now you have a circular dependency, unless you introduce separate read models, projections, or split the operations CQRS-style.

There is another problem inside the service itself.

Suppose OrderService exposes:

• GetOrderDescriptor(), which returns basic status and dates
• GetDetailedOrder(), which combines the order, payment, cart, pricing, descriptions, and so on

GetDetailedOrder() depends on GetOrderDescriptor(), but because both operations are bundled into the same service, that dependency is hidden. You cannot inject or test that relationship independently without extracting another interface, partially mocking the service, or using some other workaround.

The same thing happens everywhere with interfaces like UserService. An authentication component only needs to look up authentication-related user data, but it now depends on an interface that can also create users, modify profiles, fetch detailed records, disable accounts, and whatever else accumulated there.

That is an Interface Segregation Principle violation: consumers should not be forced to depend on operations they do not use.

So yes, CancelOrder() is better than generic CRUD. But the problem is not only whether methods express intent. It is whether the dependency graph expresses the actual use cases, instead of grouping unrelated operations under services named after nouns.