Chaos and discipline, These two words are Oxymoron, you might be thinking, How Chaos can 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. If we think about the Law of Entropy, then Chaos is the high entropy state, and a discipline is the low entropy state. Always disciplined services degrade to chaotic ones to make the system in equilibrium, as the flow of the direction is from high(Chaos) to low entropy(discipline) state. So chaos is inevitable. Now, If we want to ma ..read more

 While we are talking about Microservices, we talked 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 Green Field 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 decomposing your Business domain logic(Business Space) and mapped it with Microservices architecture(Code Space ..read more

  I have heard many times below question  " How do I scale Microservices?   or What type of Scaling Microservices unlocks?"  So I thought to write a crisp article on the Scaling. A distributed system can always be scaled in a 3D space, i.e X axis, Y axis, and Z axis, and we need to scale distributed system to manage the load and having a high availability of the website and of course managing the cost in an efficient manner by maintaining servers/other resources optimum way. X-Axis offers to spawn the environment based on the load, the old way of scaling distributed ..read more

Although the question is Simple, it is tough to answer as Microservice does not have any de facto standard, many people have many perspectives on Microservices so many definitions. The compelling definition is. Microservices is a Suite of services where each service is, bounded by a bounded context and can run, deployed, and scale independently without impacting other services. So, to make the above statement correct in reality, organizations that are adopted Microservices follow few common characteristics, so Javaonfly recommends, rather than going by definition go for Characteristics. C ..read more

  "Composition and Inheritance are the atoms of Pure OOO design. One can't be replaced by others. Two have their own purpose,  Most of the time developers use Inheritance in the wrong way and it looks  Composition is the better option.  One of the signs of using Inheritance the wrong way if you suppress a parent method by throwing "not implemented exception" or by silent/empty implementation. To restrict that silly mistakes, Seniors often giving the above mantras without thinking about the context, but it does not fit always." To know in detail please follow#javaOnFly , w ..read more

  Tips:: "To Me, CLean code is the Developer's Emotion, a code maintaining a classical design or badly written, both are two extremities and must be avoided, as per statistics we have a large number of developers who wants to see code as simple methods and classes combination with   readable variable names neither a grand design nor an unreadble code." javaOnFly started a new segment called Tips corner, every Saturday we will post Tips only for you to make you a better programmer. If you Like the Tips want more about the topic , you can read a whole bunch of detailed Java Art ..read more

  Every time I look at the Getter methods, I wonder, a simple getter method but its impact is very high on the code.  Is it a friend for developers or enemies who are acting as friends?  We can discuss various topics on Getter but here I would focus on one topic, which impacts codebase severely and forcibly implementing coupling and breaching the encapsulation.  The most interesting part is that in some cases Getters can cheat the “Law of Demeter†rules, welcome coupling, and breach encapsulation.  So it creates confusion for developers and as an outcome, we ended ..read more

 We all know what is a dystopian world -- A world of Chaos or Injustice, for developer Antipattern, is the dystopian world but surprisingly willingly or unwillingly developers love to live in a dystopian world. Jokes apart, but this is the ground reality for most of the Legacy or old projects, common experience for developers are they change in one place, it breaks in another place. This has happened due to three major factors. Tight coupling and complex codebase. Multiple God Objects are driving Business Logic. Inexperienced coder and tight timeline. I have discussed enough ..read more

 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. So, the first tip. Always put validation on the input argument, you can use java annotations to do the validation. Now, let's think about what we do in a method after receiving the inputs. Most methods will do three things ..read more

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. It is time to quickly recap the definition ..read more