With this post I’ve taken a bit more of a practical turn compared to previous Post-Architecture posts: It’s more aimed at providing guidance to keep (early) architecture as simple as possible. Let me know what you think!
With this post I’ve taken a bit more of a practical turn compared to previous Post-Architecture posts: It’s more aimed at providing guidance to keep (early) architecture as simple as possible. Let me know what you think!
@agressivelyPassive moving from ‘storing a user in postgres’ to ‘storing anything in postgres’ is a step up in abstraction. Same with moving to ‘storing a user somewhere’ or moving to ‘storing anything anywhere’.
Moving from ‘storing an entity’ to ‘storing an entity via a FacadeBuilderFactory’ is not a step up in abstraction, it’s only an extra indirection.
No, that’s my point. Providing the builder factory as an abstract way to construct an entity, it is an abstraction. It removes you from the actual detail, that’s an abstraction. But it also introduces extra complexity, which in turn negates the value of the abstraction.
In reality, the intention is an abstraction, the result is often enough a bad abstraction that introduces more complexity and adds indirection.
@agressivelyPassive if you routinely call indirections abstractions, then ‘premature abstraction is the root of all evil’ holds. If you separate the two concepts, you might think differently.
If my team’s codebase had a business logic class that had a concrete dependency on an EntityBuilderFactory, I’d vomit a little, but I wouldn’t delete it (can’t piss off too many people all the time). But I would route around the damage by allowing the class to depend on the EBF *or* something else.