Discussion about this post

User's avatar
John Obelenus's avatar

Interacting with 3rd party vendor APIs comes to mind for this pattern. You have no ability to change their API, it is immutable. It doesn't match up with what you're actually trying to achieve with your business logic. Write the interface to that API from the business logic *that makes the most sense for the business logic*. And within that sectioned-off layer/library/module, you can deal with the messiness of translating the data into the shape the API demands.

Expand full comment
Aslam Khan's avatar

Leaky abstractions are good candidates. At some point we need to stop the leakage of internal implementation to the caller and this is a good way of arresting that. Another, perhaps related, is an API at the wrong level of abstraction. Some message queue API's come to mind that reveal the mechanics of the message broker and not the semantics of messages and queue.

This gets my vote for being included in the final copy because the application may be rare but the problem is fairly common.

Expand full comment
15 more comments...

No posts