A common idea in enterprises is to share and reuse technology as well as commonly used data. Earlier we looked at sharing Java modules and the shortcomings with that. What about sharing common technology or data models in distributed systems?

Multiple applications that form an enterprise system are often implemented using similar technology. This comes naturally with applications that are built by a single team or teams that work closely together. Doing so very often raises the idea of sharing technology that is being reused in the applications.

Projects could use commonly used modules that remove duplication in the overall system. A typical approach for this is shared models. There could be only one module within the organization that is being reused in all projects.

Sharing models leads to the question whether potentially persisted domain entities or transfer objects are being reused. Domain entities that are persisted in a database could then even be directly retrieved from the database system, right?

Commonly used databases stand in total contradiction to distributed systems. They tightly couple the involved applications. Changes in schemas or technology welds the application and project life cycles together. Commonly used database instances prevent applications from being able to scale. This eliminates the motivations behind distributed systems.

The same is true for sharing technology in general. As shown in previous chapters, commonly used modules and dependencies introduce technical constraints in the implementations. They couple the applications and limit their independence in changes and life cycles. Teams will have to communicate and discuss modifications, even if they would not affect the application's boundaries.

Looking at the domain knowledge and the responsibilities in the context map of the system, sharing data and technology makes little sense. There are indeed points of contact between the systems that are subject to be shared in technology.

However, the point is to implement applications, which only depend on their business responsibilities on the one side and documented communication protocols on the other side. It's therefore advisable to choose potential duplication and independence rather than coupling in technology.

Sharing other concerns rather than points of contact in the system's context map should alert engineers. The application's different responsibilities should make it clear that commonly used models or data reside in different contexts. The individual applications are exclusively responsible for their concerns.