System Configuration. How far should we go?
I recently started a project which required the re-design of the system to enable a highly configurable architecture. The system itself is already built on a framework which enabled a whole bunch of cool functionality and patterns. One of these functionalities was a business rule meta data collection object which provided meta data about fields. This function provides meta data down to the UI (for rendering required field/field visibility etc), and also consistent automated validation of business rules. The benefit of this approach is the business rules are set in 1 place. No need for any logic to be processed in the UI making the UI like a dumb renderer, in that this layer renders stuff, and that's it. This also means unit testing can have a much higher impact as we can test our business logic.
So with this design in mind I started building a configuration structure which allowed the setup of this meta data. There by allowed business rules to be set via this database configuration structure. The design was only an initial design, but this is where it stopped. When I showed it to the senior dev, he suggested this design was not good enough. He pointed out the huge number of configuration points required to be populated in the database would be hard to maintain. Also the lack of separation between the business Logic and the presentation layer. My design actually contained a reference to the property in the Dto, and also the display name which could be used for the label in the UI, which was also used for adding to the error collection when the validate method was called. His main concern was that there was already a proven way of dealing with labels in .net using resources files and satellite assemblies.
This design was dropped, and in it's place we can up a configuration strategy based on business function. We have a status table, which we added a bunch of column, 1 for each business function. This function was either on or off, and then we could develop code which could use this flag to determine how to set required fields, field visibility, etc. etc. This meant heaps less configuration data added to the database, and a seeming more obvious configuration regime.
This method was fine when we started. but how quickly this became a nightmare to manage. Each flag had a kind of specific meaning, until we started using a flag just because it was turned on in the right scenarios. Suddenly, this meaningful configuration switch was just a misleading word used by the code to do something. So when developing new code, we either add another meaningless flag to the table or we use an existing flag, which could have a different meaning to our understanding, and potentially miss use the flag. I'll give you a real life example I am currently working on.
We have a project, and the project has a status. during the life cycle of this project the status will change, and each time the status changes different business rules must be applied. A very typical scenario. And a very simple request, when the project moves to a particular status, a particular field is required. now remember, we are not coding anything on specific values, such as a single status, but rather flags determining business function. First stop, check the validation rules, and see which flag determines if the field is enabled, but wait what does close_out mean?? I specifically don't give context here, because this is exactly how I felt when I was requested to make an informed decision of how to implement this new request. Now all these configurations are tightly coupled to someones interpretation of what defines a business function.
The second step of this design was to use the Microsoft best practice resource files/satellite assemblies to deliver the label changes. I agree that best practice is always a good start. However, I don't think you should blindly implement, as each solution is different and requirements and circumstances can be different, after all best practice isn't always best fit. By choosing to use the MS best practice approach we have introduced a new complexity were labels need to align to the validation rule. Since Labels are handled in the resource file, and validation rules are built in the service layer, the service layer inherently needs to know about the presentation layer. It has also introduced a new something to maintain, and to keep aligned with the business rules wherever they may be implemented. Decoupling these two tightly intertwined elements just for the sake of best practice has caused a whole other layer of complexity which must be managed.
I am but a pawn in this development process. I must admit, something just doesn't seem right. If you disagree, I would love to know your thoughts. I'm not really sure which is the better approach. If I could re-do the project again, I would try it just to see. Maybe next time!!
So with this design in mind I started building a configuration structure which allowed the setup of this meta data. There by allowed business rules to be set via this database configuration structure. The design was only an initial design, but this is where it stopped. When I showed it to the senior dev, he suggested this design was not good enough. He pointed out the huge number of configuration points required to be populated in the database would be hard to maintain. Also the lack of separation between the business Logic and the presentation layer. My design actually contained a reference to the property in the Dto, and also the display name which could be used for the label in the UI, which was also used for adding to the error collection when the validate method was called. His main concern was that there was already a proven way of dealing with labels in .net using resources files and satellite assemblies.
This design was dropped, and in it's place we can up a configuration strategy based on business function. We have a status table, which we added a bunch of column, 1 for each business function. This function was either on or off, and then we could develop code which could use this flag to determine how to set required fields, field visibility, etc. etc. This meant heaps less configuration data added to the database, and a seeming more obvious configuration regime.
This method was fine when we started. but how quickly this became a nightmare to manage. Each flag had a kind of specific meaning, until we started using a flag just because it was turned on in the right scenarios. Suddenly, this meaningful configuration switch was just a misleading word used by the code to do something. So when developing new code, we either add another meaningless flag to the table or we use an existing flag, which could have a different meaning to our understanding, and potentially miss use the flag. I'll give you a real life example I am currently working on.
We have a project, and the project has a status. during the life cycle of this project the status will change, and each time the status changes different business rules must be applied. A very typical scenario. And a very simple request, when the project moves to a particular status, a particular field is required. now remember, we are not coding anything on specific values, such as a single status, but rather flags determining business function. First stop, check the validation rules, and see which flag determines if the field is enabled, but wait what does close_out mean?? I specifically don't give context here, because this is exactly how I felt when I was requested to make an informed decision of how to implement this new request. Now all these configurations are tightly coupled to someones interpretation of what defines a business function.
The second step of this design was to use the Microsoft best practice resource files/satellite assemblies to deliver the label changes. I agree that best practice is always a good start. However, I don't think you should blindly implement, as each solution is different and requirements and circumstances can be different, after all best practice isn't always best fit. By choosing to use the MS best practice approach we have introduced a new complexity were labels need to align to the validation rule. Since Labels are handled in the resource file, and validation rules are built in the service layer, the service layer inherently needs to know about the presentation layer. It has also introduced a new something to maintain, and to keep aligned with the business rules wherever they may be implemented. Decoupling these two tightly intertwined elements just for the sake of best practice has caused a whole other layer of complexity which must be managed.
I am but a pawn in this development process. I must admit, something just doesn't seem right. If you disagree, I would love to know your thoughts. I'm not really sure which is the better approach. If I could re-do the project again, I would try it just to see. Maybe next time!!
Comments
Post a Comment