I work on a big 10 year old application (500k blocs of code) with some really bad choices:
- No unit tests
- an Anemic architecture But in a great company:
- A QA team who test regressions
- A small team (5 dev only)
- Times to make clean code
- A project of rewriting the application with new technologies As you imagine, the QA teams are a big bottleneck and everything that can reduce test regression is good.
With rewriting the CTO wants :
- unit tests :)
- A Microservices architecture with :
- One service by feature with duplications between services
- A single database
- A single repository, but one makefile by service
I agree that Microservice can avoid regression, but I think it's too complicated. I don't want to have to manage database conflicts or update 200 services each time I change the database...
My guess is, with:
- Unit tests
- Open/Close principle
- And maybe SOA (1 service by bound context) We can almost avoid regressions and it will be a better start if we really need microservices. What do you think?