Everyday Reflections

This is a very light post on vertical decomposition and by no means is most comprehensive read on this topic! It is meant for engineers and product managers that are looking after or working in such initiative to resurrect their current approach or pick something new from the examples.

Vertical decomposition powered by micro-services is a handy approach while trying to break down applications which appear to be black-boxed and contain objects with too many responsibilities. This complex overlap causes unwanted extension in data structures and creates convoluted schema that albeit powers the application but fails to provide right level of elasticity for absorbing ever changing needs of business.

Vertical decomposition can help you break down the application that encapsulates single business domain such as order , search , customer , product etc. In turn these single business domains should have concrete resource definitions with right level of granularity powered by micro-services to expose their

• Functions
• Configuration
• Events
• Discoverbility

While looking at vertical decomposition , one needs to spend time and decide which pieces need to be decomposed and how an incremental migration of same would take place.

Some great examples where you will find a particular resource having multiple responsibilities is as follows [ not comprehensive but enough to drive home the point ] :

• Cross Domain
  • Customer carries definition on discounting that is linked to products
  • Customer specific products are linked to the product model
• Complex Structure
  • Customer carries definition of tiers with logic and rules attached to it
  • Ordering pattern combines buying and promotions together

…

Such scenarios clearly help you identify radius of operation and allow you to start breaking down aspects of complexities with primarily two things as drivers:

• Break things which are simple in nature and help you lay foundation
  • Example : [ assigning loyalty tiers to customers ]
  • Break Loyalty program out from the customer
• Identify dependencies that reduce reliance on your current monolith [ follow anti-corruption design in case dependency exists ]
  • Example : [ login service ]
• Carve out independent services that can expose required functionality without going back to monolith
  • Example : [ Separate discount from customer as product discount or separate promotions from buying operations ]

If you are some where above and started to experiment then for sure your delivery teams are comfortable with building micro-services and ready to go. However you may hit roadblock as the deconstruction process is not an easy one. Domains are over-lapped and need to break down that one resource which does it all. One of the key things to achieve that is start imagining distributed systems and finding a “best-of”breed” approach to separate by keeping persons in mind mapped to domains and then to best of breed architecture. This way you would be able to spread the system as  a platform and created separation of concerns which can then start to shape up the action map for the persona and domain.

Achieving this is not a one day’s job and requires us to ramp up on many fronts as an organization. The safety net in doing so should be always kept in mind so that you can ensure to isolate or promote basis the phase outcomes before we proceed. The whole exercise will start with broad funnel approach and then start to narrow down eventually leading to spurt of services that control separate domains and talk to each other in a contractual approach.