I recently read Clean Architecture by Robert C. Martin. The book gives a simple advice: don’t depend on details! For Uncle Bob details are things like the database or message broker. Your architecture shouldn’t depend on the actual implementation of those details. Whether you are using Oracle, MySQL or DynamoDB, whether it’s ActiveMQ, Kinesis or an in-memory Guava event bus - your architecture shouldn’t be affected.
Don’t depend on details has some advantages:
- As you don’t depend on the actual implementation, you can change it. You can decide to use DynamoDB instead of MySQL because you want to migrate to AWS.
- You can test your code more easily. As you don’t depend on an actual implementation you can use mocks or an in-memory variant for testing and local development.
- You can change your mind. Being independent gives you the freedom to change things in the future.
Today I updated one of my demo projects on GitHub. I replaced Guava’s event bus with Spring’s own event bus implementation. Both implementations do exactly the same - they send events. However, my code had a strong dependency to Guava. Each and every listener imported an annotation from the Guava library. A detail on which I depended.
The result was this pull request:
Although the implementation of Guava and Spring are doing exactly the same, I needed to change 18 files. There were no tests and it’s just a small and stupid demo project - still, I needed to touch 18 files in order to switch from one in-memory message broker to another. This shouldn’t be the case! Don’t depend on details!
More
Best regards, Thomas.