Why Commit Scope is Indispensable
Reading time: ± 8 minutes
The reality of growing Mendix applications
Almost every Mendix app starts the same: small, clear and with a clear scope. A few entities, a handful of microflows and short lines within the team. In that phase, Mendix feels exactly as it was meant to be: fast, productive and pleasant to work with.
Success changes that image. More users means more wishes. More wishes lead to more functionality, additional entities and new microflows. Teams are growing, releases are coming faster and what was once a compact application is slowly becoming a mature landscape.
So far nothing special: this is what growth does. The real problems usually do not arise during the first construction phase, but afterwards. When the application is live and minor changes become part of regular releases.
In that phase, recognizable symptoms appear. A commit has unexpected side effects. A validation turns out to be ‘somewhere else’ than you thought. Microflows do just a little more than what feels comfortable. And some bugs only show up in production, as if they have a pronounced dislike for test environments.
These are no exceptions, nor are they signs of poor development work. These are typical consequences of an application that has grown without explicitly considering responsibilities, transactions, and interdependencies. Or in other words: the complexity did not arise all of a sudden, but slowly crept in.
Commit Scope was born as MxBlue’s answer to exactly this phase of maturation. Not to limit the speed of Mendix, but to keep a grip on behavior, data and quality even with further growth.
Why Commit Scope is needed in growing Mendix applications
Commit Scope was born from one central question: how do you keep a growing Mendix app manageable without relying only on discipline and agreements?
When an application matures, we see the same three quality goals come under pressure in practice: data integrity, maintainability and testability. Not as abstract architectural principles, but as concrete problems that manifest themselves in daily development work.
Data integrity is often the first signal that something is starting to shift. As functionality grows, it becomes less obvious which objects functionally belong together and need to be changed together. Small changes in subsequent releases can then cause unexpected regressions, resulting in data that has been stored in a technically correct way, but no longer is functionally correct. It is precisely these subtle inconsistencies that are insidious, because they often only show themselves later and are difficult to repair.
Maintainability usually follows not much later. Microflows grow with the application and take on more responsibilities, intertwining logic for interaction, validation and business rules. The code continues to function, but it becomes increasingly difficult to read, review and modify securely.
Testability is rarely separate from these two problems. Implicit commits, hidden validations, and side effects in UI flows make it difficult to set up reliable automated tests. Tests sometimes fail and sometimes don’t, or miss exactly the scenarios that do go wrong in production. As a result, trust is once again shifting to manual checks and caution, which further slows down further development.
These problems reinforce each other and make each subsequent change more difficult than the last. Before you know it, you’re in a circle that neatly maintains itself, with the only real innovation being that everything takes more time. Commit Scope aims to break this cycle by providing explicit structure around transactions, validation, and responsibilities.
Commit Scope vindt zijn oorsprong in het Menditect Testability Framework.Not as a copy, but as our interpretation of the idea that quality is a design decision, not a correction mechanism.
The three core principles of Commit Scope
The problems we described above do not need exotic solutions. They mainly ask for explicit choices. Commit Scope is built around a small number of principles that together ensure predictable behavior, without unnecessarily limiting the flexibility of Mendix.
1. Explicitly determine what belongs together
The first principle is perhaps the most important: before you commit something, you explicitly determine which objects functionally belong together, i.e. the Commit Scope. Not from a technical perspective, but from the business logic of the application.
In many applications, this happens implicitly. A microflow touches multiple entities, commits take place in a scattered manner and the mutual coherence is mainly created by chance and order. Commit Scope turns this around. You consciously define which entities together form one consistent change and therefore need to be committed together.
Typical examples are an order with corresponding order lines, a patient with measurements or a contract with his versions. By making this connection explicit, you prevent the database from temporarily or permanently ending up in a functionally invalid state.
2. Validate before you commit
The second principle follows logically from this. If you know what you are going to commit together, you can also fully validate before anything is written to the database.
In many Mendix applications, validation has become distributed: part is in the UI, part in microflows and part in entity events. That works, until it doesn’t work anymore. The moment when you realize that ‘somewhere’ was apparently also an architectural choice. Error messages become unpredictable, and tests have to deal with hidden rules that only become active under specific circumstances.
Commit Scope makes validation explicit and deterministic. Everything that should apply for a consistent commit is checked in advance. Only when the full set of objects is valid, the database transaction follows. This gives control over error handling and makes validation logic findable, reusable and testable.
3. Separation of responsibilities
The third principle is the separation of responsibilities. Not as a theoretical exercise, but as a practical means of limiting complexity.
Commit Scope uses a clear layering. Interface logic is responsible for interaction and inputs. The process layer orchestrates the use case and determines the commit scope. Entity logic includes validations, database transactions, and business rules. Each layer has its own role and does as little more than that as possible.
Microflows are becoming smaller and more predictable. Logic becomes reusable. Or in other words: the application will not necessarily be simpler, but it will be more understandable.
Where the challenges lie
Commit Scope is a conscious design choice and therefore also a demarcation. The pattern explicitly optimizes predictability, data integrity, and maintainability, and not maximum throughput in all situations.
That choice requires a different way of working. Structure often pays little attention to our desire for speed. Due to explicit commit moments, centralized validation and stricter structure, Commit Scope deviates from common Mendix patterns such as extended entity events or implicit behavior spread over microflows. That can feel uncomfortable at first, but the inconvenience is even greater with bugs in production.
That makes Commit Scope not an obvious choice in every situation. The pattern fits especially well with business-driven entities and use cases with clear transactions, where inconsistency has direct impact and stability is more important than pure speed. The pattern is less suitable for technical or supporting entities, such as logging, staging or derived data, and for high-volume or performance-critical paths such as bulk imports or large synchronizations. In those scenarios, the extra structure mainly introduces overhead, without sufficient added value.
The core of the consideration is simple. What is a feature in business logic, namely explicit validation and control, can actually become a disadvantage in throughput-driven scenarios. Commit Scope is therefore not a dogma, but a tool that must be used consciously and selectively.
Who is Commit Scope for?
Commit Scope is not a universal pattern, but especially relevant when applications and teams reach a certain scale. Often after a few small changes have shown that ‘small’ is a relative term.
For Mendix developers who want to look beyond “it works now”, Commit Scope offers a way to structurally keep a grip on growing complexity. IT project leaders get more predictability in quality and less dependence on individual knowledge or experience. And for Product Owners, it means fewer regressions and more confidence when releasing new functionality.
Or in other words: Commit Scope is especially interesting when stability, maintainability and predictable behavior become more important than maximum speed in each individual change.
Conclusion
Commit Scope isn’t about how you commit, but about when you decide something is right. And it is precisely that decision that you do not want to arise implicitly.
The pattern is therefore not an accelerator. It is a stabilizer. And you need it especially when the pace increases, the impact increases and quality can no longer be a coincidence.
Author: Stephan Wolbers – Head of Technology & Innovation MxBlue | SUPERP
