Business Logic Should Not Know About Data Mechanisms

In my line of business, training software developers to engineer simpler, more maintainable software, I get to review many codebases. In the minority of cases that a Clean Architecture approach is discernable, one design mistake is invariably still present: Data access interfaces belonging and used by the business logic hint at the data access mechanism. For example, it is not unusual to see pure business logic utilise interfaces such as

• ICustomerCache
• IOrderQueueAdapter
• IInvoiceMongoDatabase
• IUserFileReader or IUserFileWriter
• and so on.

Why is this problematic? 

Let’s recap the function of business logic in our code.

Business logic is about WHAT the system does—not HOW it does it.

It’s about registering a new customer in our system and the high-level steps involved in this process. It’s not about the mechanisms—whether we use web or mobile or MongoDB or a Cache or a remote service. 

Therefore, if business logic wants to save a Customer, why should it care whether Customer data is pushed into a cache, a database, onto a queue or calls a remote service or is written to a file? Too right—it should not. 

If we leave traces of implementation specifics in naming our interfaces, we are making our software unnecessarily rigid. When we then want to migrate from one data access mechanism to another, we may have to rename these interfaces. Given these interfaces are meant to be abstractions protecting us from implementation detail, we then go ahead and put implementation details right back into the name!

So, what does this mean for naming our data access interfaces? We should give them neutral names like: 

• ICustomerRepository
• IOrderDataSource
• IInvoicePersistor
• IConfigurationWriter
• and so on.

In turn, implementers of these interfaces should have clear and implementation-specific names, like:

• AmazonSqsCustomerAdapter : ICustomerRepository
• SqlOrderDatabase : IOrderDataSource
• SalesforceInvoiceClient : IInvoicePersistor
• FileConfigurationWriter : IConfigurationWriter

So please remember that your Business Logic should be ignorant of data access mechanisms. This ignorance should extend to the naming of the abstractions representing these mechanisms.