loading...

re: Don't code your microservice like a monolith, keep it maintainable not over-engineered VIEW POST

FULL DISCUSSION
 

It’s indeed an interesting read! Just to offer a different take, I’d say that it really holds about the infrastructure, but that the business rules have to live somewhere. And even considering only one part of the business domain is in each micro service, it still should abide by good code design principles.

Because when it comes the time to “add just that new feature”, you’ll want to have your code flexible enough to sustain it, and not go make another service because, well, things are getting too messy. (I’m not saying that’s what you propose, though) That way you’d be just transferring code complexity to orchestration complexity, and an http mess...

So, if it’s an OO language, I think you should take just enough time to model your domain properly, put the necessary interfaces in place, use the appropriate design patterns, and then go do your next thing. A micromess is still a dangerous mess, and a pretty micro application is probably never going to bite back at you.

Does it make sense to you?

Thanks for the insightful reading!

 

Yes some parts you wrote surely makes sense. The thing about http level complexity tools like kuberernetes help a lot to handle it. Thanks for your views.

code of conduct - report abuse