Managing dependencies in Mendix

From Monolith to Microservices

Andriy Levytskyy
Feb 16 · 3 min read

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.

DSM matrix for a Mendix app

In the above figure, the app’s modules are labeled in the rows to the left of the matrix and in the columns above the matrix. A non-empty cell in column A and row C represents a dependency of A on C (a convention at Radiuz is that non-empty cell indicates a number of dependencies). The cells along the diagonal represent relationships within an element and are not filled in. Rules that specify the architecture of the app are represented by the background colour of each matrix cell. At Radiuz we defied the following DSM extensions:

  • allowed dependency (green cell)
  • undefined yet (yellow cell)
  • unwanted dependency (red cell)

Keep in mind that If there is no architecture defined for an app, then the technique can’t help tell which dependencies to eliminate. The shown application is built according to:

  • a generic layered architecture, which prescribes that relationships are allowed only under the matrix diagonal.
  • a Radiuz-specific domain architecture, which further constrains and overrules the layered architecture, as indicated by non-red cells above the diagonal and by non-green cells below the diagonal.

After a few months in use, experience of our development team was positive. In their words, they finally had an understandable and accessible explanation of the architecture, which they could consult directly without having to wait for an architect. The team has been using the matrix to develop new functionality and refactor existing functionality in conformance to the architecture, all autonomously. The graph below shows the statistics of unwanted dependencies after each sprint. After the initial period of learning the technique, the team has been improving the app. Towards the end of the graph, statistics regressed as project stress increased due to an approaching major milestone.

Unwanted dependencies trend

One wish of our developers is to be able to update dependencies of this matrix instantly by press of a button. A number of off-the-shelf tools are available for software engineers to create DSM, e.g. CAM (a free research tool), NDepend and Lattix. None of them directly compatible with Mendix platform. Radiuz eventually settled on a spreadsheet. As of now, the architect has to manually fill-in the matrix with usages data from a Mendix project. The whole process takes approximately an hour for an application with 22 modules. Given how close this matrix is to the information already available in each project, we hope that Mendix will consider adding this feature to their platform.

Do you have best practices or lessons learned from managing dependencies? I would like to hear from you. Please share your experiences in comments below or contact me via linked-in.

Andriy Levytskyy

Written by

Platform architect at Radiuz B.V., where I am primarily responsible for evolution of our mobility platform towards a distributed architecture.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade