Volatility Based Decomposition Example
Requirements change, software changes. How can we soften the pain of change? Here’s a little example of how volatility-based-decomposition could help. Although I don’t show a top-down decomposition, this exemplifies ‘composition smells’ based on requirements.
Disclaimer: I’m still learning volatility-based decomposition. So, if there’s anyone reading this that knows better than me, please comment to correct me, and I’ll update this story. That being said, let’s see how this story could provide as an example for encapsulating volatility.
If you’re not familiar with volatility based decomposition then either google it or check out a preview of book (I promise I’m not affiliated). This example should cover the idea without explaining the theory upfront.
So, we have some broad requirements (happy path):
- Once a customer has requested registration we need to process a credit check
- If their credit check passes then check their address
- If their address is valid then register the customer
If we were to build an architecture based on these requirements we’ll get something like this:
We may implement this architecture design and be happy for a while. But there’s something that smells here. We have two services (Credit Check and Address Check) that are implementing specific requirements. Are they trying to satisfy a common goal? What if the requirements change? If so, then we’d need to change the services and the connections between them.
We can see that actually the two specific requirements for processing checks are a part of just checking if the customer is eligible for registration. Can we look beyond the specific requirements and derive the business goal? - “a customer can only register if they are eligible”. Furthermore, could the way we check for eligibility change? Could the specific requirements change? Is there potential volatility here? With that in mind, lets carry on with designing against the specific requirements.
Then one day the business demands we need to also need to perform a criminal check — new requirement!.
Now we need to create a new service and change our connections. If we’re in the world of microservices then we’d need to change Address Check service and Customer service, just to rewire.
It’s even more evident now that our checking process is prone to change, thus volatile (yes “Everything, in retrospect, is obvious”, but it was smelly before). We’d want to encapsulate this volatility, as the business is likely to change their requirements again. We’re essentially reducing the dimensions of requirements into a more stable architecture.
We could combine all the ‘check’ services into one Customer Onboarding service. Firstly, the business would thank you for reducing infrastructure costs. Secondly, if you need to change the code to fit the requirements, then you can easily do it within a single code base (service). However, they can still be separate services, but the connections are private/encapsulated. Either way we’re encapsulating the business volatility. From the outside the Customer Onboarding service is stable, but internally it can endure a lot of volatility. But the volatility will only affect that service. Look at the input event (registration requested) and the output (customer checked) — it acts as an interface, all the internal events are black-boxed.
Read the requirements, pull out the most important and stable classes of requirements, then design against that. This converges with domain-driven-design very well, with a few additions. The salient point is to understand the business goals and seek the parts with stability vs volatility.
Again — please comment to correct or contribute, it’ll only help myself and the readers to improve how we forward value. This example architecture story was stolen from Bernd Rücker in his talk. But this story was looking at it from the perspective of volatility-base decomposition. I’d highly recommend watching his stuff!
Cheers
