Maintaining Model Integrity through Bounded Context and adopting Microservices

On the one hand we see there is a paradigm shift in the world i.e the Software representation of the World to move to a "No Strings Attached" decoupled architecture with the adoption of Micro-Services Architecture because of the alluring value proposition it has in terms of agility and scale.  

At the same time the dynamism of one aspect of Businesses i.e the Mergers and Acquisitions lead to Enterprises taking a totally opposite route. A stark anti-pattern seen in many Organizations to try and "Unify Applications / Contexts, make a suite". This definitely challenges and adversely impacts the Integrity of the Domain Models of the Software eventually leading to the integrity of the applications comes under very real threat / challenges. 

 Typically in such cases and Organizations there are a number of prima-face genuine Business reasons may be and are cited by the proposers to integrate contexts for e.g. 

• A common and consistent security model for all applications of the same enterprise. 
• Common Application Governance framework for all applications of the enterprise.
• Common Resources being optimally shared across all applications of the enterprise.

While an argument (however strong it may be) can be put that these all are very valid Business and Management objectives and there are efficiencies, there are many different strategies available to address each of these challenges without diluting model integrity.  However when any of the afore-mentioned or any other objective is at the behest of Model Integrity (which means here the Integrity of the Domain Model which is the heart of an Enterprise Application) than we need to tread the path with utmost caution. 

  Merging disparate contexts can create real problems. 

 Lets take the typical example of Merging the User Model of two applications leads to the following problem. 

• Where do you define a distinct user who has the necessary authorization to relevant modules of potentially n different applications.
• Whether to duplicate the users and have an independent data store and user model in each application then how do you keep the user model in sync if one of the user is also promoted to an Enterprise user.
• Merging the User Model can create potential Referential Integrity Problems if these are updated when they are merged to take on new definitions, for e.g. User 1 had a PK of 334455 in one system and there are transactions stamped in the application quoting 334455 now as part of a model merging exercise if the user now has an id of 667788, then either a mapping needs to be maintained to keep transnational continuity for audit purposes with expensive lookup every time or there is a massive update exercise. However it may still not work when such users data with the reference is to be reported for regulatory purposes.

Of-course with the passage of time solutions are discovered for each problem. These solutions are often found to be missing not so acute angles of extra maintenance of the software and additional hurdles in future change to be seamless to the system.

A lot of thought process has been already put into this by stalwarts like Eric Evans has described the importance and keeping the integrity of the model in his seminal work Domain Driven Design : Tackling complexity in the heart of software.

To quote Eric Evans from DDD 

"Multiple models are in play on any large project. Yet when code based on distinct models is combined, software becomes buggy, unreliable, and difficult to understand. Communication among team members becomes confused. It is often unclear in what context a model should not be applied"

Therefore: "Explicitly define the context within which a model applies. Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas. Keep the model strictly consistent within these bounds, but don't be distracted or confused by issues outside."

Of-course various applications of an Enterprise need to interact with each other but these interactions should be strictly through APIs. The real problem is when Enterprise try to create an artificial facade of a One Enterprise (SSO / Suite / etc) and force Heterogeneous Applications and hence their Models to be merged which causes the problems. 

The micro-service architecture which is far more accommodating for Heterogeneous systems and is non-discriminatory whether these applications / systems are from different enterprises or the same enterprise comes to the rescue in these cases and makes pragmatic and altruistic Design sense.

Clear Bounded Context for each different application helps reinforce model integrity and reliance on APIs for exchange of optimized messages keeps the requisite exchanges going on between the applications. If there are still use cases which may potentially warrant a merging of models still it will be focused and restricted if mandatory and not a Kitchen Sink approach. 

It is a Win- Win for all with this kind of adoption. Add to it the auto-scaling and containerization benefits and you have an unbeatable value proposition.