Managing dependencies in Mendix

From Monolith to Microservices

If you watched the Mendix webinar on integrating Microservices you may have wondered how an organization can prepare a monolith-ish application for transition to microservices. Mendix gives a hint: painless transition requires reduction of unwanted dependencies.

So how does one oversee dependencies, let alone recognise unwanted ones? Any seasoned Mendix developer would know that the Mendix platform provides a “Find usages” tool. The problem is that a well evolved Mendix project easily contains many thousands of dependencies. In most projects, the built-in find tool would simply overwhelm developers. This article describes an alternative technique applied at Radiuz.

The technique is based on The Design Structure Matrix (DSM; also referred to as Dependency Structure Matrix). DSM is a compact way to display the structure of relationships between elements in a complex system. Common examples of these elements include products, activities, and software components.

Compared to a graph, a common representation of such systems, DSM is less intuitive. However, the important advantage of DSM is that it scales with large amounts of and complexity of relationships and elements, whereas a graph quickly becomes incomprehensible. Another advantage is that DSM makes structural patterns visible. And last, but not least, with DSM, you can create design rules to specify and communicate the intended structure of a system.