3 ms·
Do you need (more?) new abstraction layers or do you need extremely clear un-abstracted separations of concern? In the cases of trying to build abstraction lay
by majormajor 4y ago
Do you need (more?) new abstraction layers or do you need extremely clear un-abstracted separations of concern?
In the cases of trying to build abstraction layers in advance "in case we need them" that I've worked on, they rarely are sufficiently right-shaped for what the future feature need ends up being. Having more direct access to the primitives usually works better in terms of avoiding "the business logic is split across three layers of service calls" type of situations.
- jitl 4y agoWe share the same record types (primitives?) across the stack - but because of that sharing, those types are hard to evolve, especially when it comes to their semantics. Too much code interprets then directly, which ossifies those primitives. How to enforce separation of concern when such data structure is shared liberally? > the business logic is split across three layers of service calls we are thankfully very far from this world.
- 8n4vidtmkvmk 4y agoconvert the records at the service boundaries to something better suited for that service. then everything doesn't depend on each other
- jitl 4y agoYour advice is "add abstractions", which is basically the opposite of the grandparent commenter's advice. Right now I am on board the "add abstractions" train.
- 8n4vidtmkvmk 4y agoI suppose, but converting it to another structure isn't a huge abstraction. Maybe it can complicate things if the conversion isn't obvious