In the previous blog post, I tried to explore ideas and questions that help me determine how to correct or establish a good domain model. In this second part, I'm writing about the process of implementing those changes as compared to traditional application development.
Depending on how far along the application is in its maturity determines the impact a design change will have. If they are dealing with a mature application are they truly stuck? Thankfully, no, and Mendix makes changing the model relatively painless...at least compared to standard application development.
Applications built on traditional platforms require multiple changes by multiple resources. Database Administrators (DBA's) have to solve the relationship issues and change the model by creating and editing tables, stored procedures, and a host of other items, most of which are not documented in a format that explains each and every affected object. They then must program jobs to stage the existing data and then repopulate the new model with the historical data so as not to corrupt and orphan records. There are other steps as well, and that's just the DBA's. Then there is the web platform developers that must redesign and associate the code behind their pages and forms to map to the entities correctly. As a BI guy, I can't forget about all of the downstream applications that extract records to move into other applications via ETL or API processes. Frankly, it's a very big job.
In Mendix, all of those things still need to be cared for but the Modeler makes it easy for you. Domain model changes happen right there in the tool...no need to bother a DBA to do all of this. When you make a change that "breaks" something to create errors, the tool lists those errors so you can remedy them without wondering what might have been impacted. And finally. And lastly it auto-changes all object names for you so as not to cause a conflict. For example, if you change an attribute or association name, it changes all references for you so there is no need to "fix" those pieces of code.
How to go about making domain model's right:
Determine the legacy data impact of the change.
Once you've assessed the problem and designed a solution, before you can implement it you have to figure out how it will impact legacy (production) data. In a previous blog entry I wrote about adding a 'Department' to an existing application. If I hadn't built the job to update and associate the current data in production to a single department, I would have orphaned all of the data in Production and those users wouldn't have been able to work on it anymore. You need to determine if the change to your domain model is going to impact the legacy data, and I can tell you now it almost always will. Care for it.
Model the changes in a branch
Sometimes the best approach is trial and error depending on your level of expertise in building domain models. If you understand the concepts of normality, you probably know enough to skip this and can determine the impact within the existing model and care for it appropriately with non-persistent entities and microflows. For the user with a more business-oriented background, however, I recommend you experiment.
Create a new branch. A lot of developers I come across aren't taking full advantage of this because the Business Modeler does such a good job of controlling change, but I speak from experience that it's simpler to create a branch, experiment to get it right, and then merge it rather than try to peel back domain model changes.
Within the branch, play around. Well, have a plan, but experiment until you know what is needed and the impacts it will have. Now determine if merging is the right course or editing the Main Line is a better option.
Implement your changes
This is pretty straightforward. Once you execute the changes and build a process for migrating the affected data into your new model you should be good to go. In some cases, an entirely new design is necessary which is a major undertaking and will require a full ETL (Extract, Transform, and Load) process from the existing application to the newly designed application. But in most instances this isn't the case. The beauty of the Business Modeler is that a single person can manage all of the changes in a short amount of time. This kind of control is exactly what has held up the claim that RAD (Rapid Application Development) is 7x faster than traditional application development.