Observations of a Mendix newby - comments requested

I'm still new to Mendix and I just developped (the core of) my first application in Mendix trial (2.5.6). See: https://chielharmsen.trial.mendixcloud.com. This trial was inspired by the Koormuziekbank (www.koormuziekbank.nl). My overall impression: very promissing in its claim for delivering applications without technical nitty gritty. The important pros of this: - much faster delivery - less technical specialties needed within the team - more all-round jobs - very well suited for agile development methods - very well suited to get the proper involvement from the business side. Some serious food for thought: • It seems so easy to design an entity and some forms for it. I hope this easiness will not lead to an underestimation of the effort to design a proper domain model. It seems so tempting to create an entity for the very first noun you encounter in the description of your assignment. But a true choice of which entities, which generalizations and which associations are needed can only be reached after a good understanding of the whole field (universe of discourse). • In Mendix (2.5.6) it is not possible to create validations over more than one attribute. • Neither is it possible to define a validation over associations. • At entity level, there is a field for documentation. There is no documentation field for attributes nor associations. An unexpected shortcoming in the light of “the model = the application”. I support Mendix in its efforts to put as much business knowledge as possible into the model (instead of in the code). I would go one step further: put as much business knowledge as possible into one particular part of the model: the domain model. This requires some important enhancements to Mendix. To be continued. I’m looking forward to your comments.
2 answers

Regarding your comment, its easy to build a domain model, but it's also easy to create a imperfect domain model, the following; That's one of the points where the collaboration between business and IT will be at the highest level. For me as a more business oriented modeler, that's the moment I seek collaboration with my techy colleagues. Since they can oversee the effect of choices.

Concerning your points about validation over multiple attributes and associations; Those are validations on process level. You can model these validations within microflows. That is the more appropriated and fitting place, since those validations are depending on the process steps. Validations on domain level will always be checked, modeling them within microflows, gives you the opportunity to capture them within your process and make them depending on that process
Validation rules at the domain model, use them for validation of your rootdata


Well, in hindsight most of your concerns seem to have been addressed after all that time. I think it is justified to say your remarks have proven visionary.