Opinion: better process to extract a service from big-ball-of-mud
November 24th, 2020
For the context about what actually happened, see Case study: extract a service from big-ball-of-mud
Per client application (3 of them)
Refactor to module
Refactor to library
Change to use our service (with fallback and throttle)
We would collaborate here for step 3, maybe even be involved in the earlier steps so we get to know the code base.
Simplest service possible + client library
Continue developing our service
System is 'done enough to use' in Case study: extract a service from big-ball-of-mud
Benefit - deliver value sooner
Starting in step 4 we can start providing value, instead of waaay later (step 6)
Benefit - faster feedback
We get usage feedback of the 3 services faster.
We get feedback from users in step 4
Benefit - less guessing / over-engineering
When there is no feedback, we need to guess.
Benefit - faster iteration of endpoint / breaking changes
This would create 3 interface points.
client-service <-> client-service-extracted-library <-> api-library <-> api
Our team would take full ownership of
Client team would keep full ownership of:
We would collaborate on:
This would allow us to iterate faster on the api endpoints, allowing us to introduce backwards-incompatible changes.
As long as the api-library interface remains stable (or backwards compatible), nothing needs to change.
If we need to make changes in the client-service-extracted-library, we could easily collaborate on that.
As it was (in Case study: extract a service from big-ball-of-mud), we could not really collaborate well on the integration part. We needed to 'dive in' a service we knew nothing about, with a very big scope. That's complex and hard to do, so we were less likely to actively collaborate.
Benefit - start sooner
We could start sooner because we would need less analysis.
In Case study: extract a service from big-ball-of-mud we needed analysis to understand what was going on.
Then needed analysis to see the big picture of where we wanted to go.
In the new way of working, all this could be postponed, more like lean's just-in-time.
Course: Advanced Distributed System Design - Udi Dahan (UI Composition)
This post was referenced in: