Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
Chaos and discipline, These two words are an oxymoron, you might be thinking, how can chaos make disciplined microservices?
But the universal truth is discipline means the absence of chaos, so until you have not experienced chaos you can not be disciplined.
While we are talking about microservices, we talk a lot about Domain-Driven Design, Event-Driven Architecture, Core Domain, Subdomain, Bounded Context, Anti-corruption Layer, etc.
Whether you are working in a Brownfield project or a Greenfield project, if your organization wants to adopt microservices, (assuming your organization has a compelling reason for adopting microservices, as it is not a free lunch), then you need to understand the above terms in detail to properly decompose your business domain logic (Business Space) and map it with microservices architecture (Code Space), so you can gain the benefits of microservice traits.
I have heard the below questions many times
'How do I scale Microservices?'
Although the question is simple, it is tough to answer, as 'Microservice' does not have any de-facto standard. As a result, many people have many perspectives on Microservices, and there are so many definitions.
The compelling definition is:
While writing methods, please pay close attention to the method arguments. This is the one area where the method assimilates the foreign body into its core body. Foreign material is always dangerous, you do not have any control over it, but as an owner of a method, you can put a defensive mechanism aka validation, or the anti-corruption layer of your method.
Always put validation on the input argument, you can use java annotations to do the validation.
While we are hearing tips on Clean code, the most common tip is maintaining SRP while writing class or methods, in a broader scope Module/Package/Service/API.
But Irony is, SRP is the most powerful but obscured principle in the Design toolbox, this throws a web of confusion and you are stoned by thinking should I use it in the right way or not? That's why I like to call SRP Medusa. Most of the time it succumbs us and we are ending up with anti-KISS code but If we use it in the right proportion, then we can create a cohesive and robust architecture.
To know how to write clean Method is the stepping stone of writing proper clean code. You already know common things like method should be clean, readable, giving proper names, so I will not write on this. I will focus on the flow of the method, and there are two ways to write a complex logic:
For clean code, always choose the top-down approach. There are several advantages.
As per the current trend, I see developers from Juniors to Seniors all using Spring Boot as their weapon of choice to build software. The fact that it is developer friendly and its "convention over configuration" style helps the developer to only focus on business logic. If they are unsure as to how Springs works, just reviewing a Spring Boot tutorial can allow one to start using Spring Boot — it's that easy.
Another part of Spring Boot that I like is that developers do not have to know Spring's inner details — just put some annotations in, write the business code, and voila! With that said, sometimes, you have to know how it works. What I am trying to say is that you need to know your tool better so you can utilize it like a pro.