From 2bccfb8d62ccf621e985b345d8c4d9d829fe595c Mon Sep 17 00:00:00 2001 From: Artem Zakirullin Date: Wed, 16 Oct 2024 19:20:54 +0300 Subject: [PATCH] add note about implicit interfaces --- README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index edf48d7..e1c1367 100644 --- a/README.md +++ b/README.md @@ -258,10 +258,10 @@ This architecture was something that made intuitive sense at first, but every ti If you think that such layering will allow you to quickly replace a database or other dependencies, you're mistaken. Changing the storage causes lots of problems, and believe us, having some abstractions for the data access layer is the least of your worries. At best, abstractions can save somewhat 10% of your migration time (if any), the real pain is in data model incompatibilities, communication protocols, distributed systems challenges, and implicit interfaces. -> With a sufficient number of users of an API, -> it does not matter what you promise in the contract: -> all observable behaviors of your system -> will be depended on by somebody. +> With a sufficient number of users of an API, +> it does not matter what you promise in the contract: +> all observable behaviors of your system +> will be depended on by somebody. > [The law of implicit interfaces](https://www.hyrumslaw.com/). **So, why pay the price of high cognitive load for such an architecture, if it doesn't pay off in the future?** Plus, in most cases, that future of replacing some core component never happens.