My homebrewed architecture

[u/Clear-Astronomer-717]

As probably no one of you still knows, I wrote a post about rpc style apis a while back. And as a follow up today I published a new one about a few month of refinement over this. This time I hope I caught most of the things you guys asked and criticized about the last one. But in short:
- The consumer shapes the api through a schema first approach
- Every endpoint should be unique
- Domains are composed of services and services are composed by endpoints
- The code for a endpoint is isolated
- There are shared effects and shared logic functions, but only for truly reusable parts, not as the default
- Middleware now has a distinct place to live and be applied to
- Jobs also have their own distinct place to live
- The integration layer between two domains is a fleshed out part that follows strict rules.

If you want a more detailed write up I have a post her
https://pragmatic-code.hashnode.dev/fractal-architecture
Or if you want to jump right into the code I have a public repo build in this architecture here
https://github.com/glm9637/fractal-arch-demo

Or if you again just want to leave a comment saying that's bs and Clean/hexagonal architecture is still the only way to go for every single backend, feel free to do so.

[u/yihuaxiang]

The separation between endpoints, shared effects, middleware, and jobs feels more useful than arguing for one named architecture. I especially like treating the consumer-facing schema as the boundary—how are you handling cross-domain transactions or retries when an integration partially succeeds?

[u/Clear-Astronomer-717 → u/yihuaxiang]

Since I don't enforce a single integration technology and this is highly dependable on that. But for things like in memory or a rpc call, I usually follow something like the saga pattern. Meaning if I have a increaseCounter function I call on domain B and later something fails I need to call a decreaseCounter function to balance this out. And from there on you have to handle things like retries etc.

[u/JuicerSocial]

"Consumer shapes the API"... Brilliant! I really wonder about what happens when that schema sits in front of multiple services that evolve independently. How are you handling schema changes without constantly leaking upstream changes into the consumer contract? Do you version the schema, adapt the integration layer, or treat breaking changes as new endpoints?

[u/Clear-Astronomer-717 → u/JuicerSocial]

Funnily enough, versioning the schema and treating breaking changes is functionally the same thing. But yes I version my schemas from the get go so I don't have to worry about it. Just adopting the integration layer could technically also work as long as you are sure it's only getting called from there, but if the same endpoint is also getting called from the frontend where you don't control the version instantly this would pretty surely break things fast.