[vc_row][vc_column][ultimate_heading main_heading=”Configuration Driven Development” alignment=”left” main_heading_margin=”margin-bottom:20px;” main_heading_font_family=”font_family:Raleway|font_call:Raleway|variant:600″ main_heading_style=”font-weight:600;” main_heading_font_size=”desktop:40px;” main_heading_line_height=”desktop:50px;”][/ultimate_heading][vc_column_text]New generation of applications need to be customizable and configuration driven architecture is a key feature of modern architecture. Brand proliferation in the digitized world has forced organizations to create flexible software that could be impacted by localization, role driven or platform driven. Besides being functional, applications adapt the business rules of the particular organization. These rules are intended to their customers, employees, structure, or their working devices. This current state of digital business rejects the rigid applications that do not allow them to be customized based on their customer demands. Modern tools highlight adaption and customization as a key marketing feature. Though the rigid core structure is necessary to have a stable application, modern applications also need to,
1) Be highly adaptable and changeable according to the rules settings preferred by individual users.
2) Ensure the encapsulation of customizations and settings according to the business rules.
3) Provide decoupling of the code with the settings and configurations.
This article highlights the importance of CDD, the process and popular formats to create configuration files.
Why Configuration-Driven Development (CDD)?
For a full stack web application with a front-end, back-end, API’s, clean architecture is crucial in developing web applications that are flexible and easy to maintain over a long span. The traditional model-driven method for application development leads to information duplication at each stage of the development process. Having Configuration files will clear the code clutter that is traditionally done with basic rule driven validations, permissions and static/dynamic messages. These configuration files are read by their respective applications during build and at run time. These configurations are used to create the structure of the application. Applying CDD to flexible applications,
- Allows developers to focus on core business and custom features that are independent of the code.
- It determines the pertinent information that is already present in existing configuration and thereby cuts down on duplication of logic and code.
- Configuration files are easily manageable using custom Configuration Management tools. They can be source-controlled and stored in a versioning system such as Subversion or CVS like the way source code is managed.
- CDD is not tied to one specific programming language. The representation of configuration is in a neutral format, and the same is used across several different programming languages.
- Behavior of the software can be changed without having to recompile or redeliver the code.
How to Choose Configuration format?
Multiple formats represent the configurations used in CDD projects. At BundleN, we provide different choices to represent and store configurations files. Some of the popular format choices for the configuration files are,
1) Having environmental variables as one of the formats for their OS. These configurations may differ for each OS.
2) Having a customized and homegrown format created by developers. The parsing and validation logics are written from scratch.
3) Using key-value format to create configuration information. These are easy to read, write and interpret.
4) Using JSON format for configuration information. This is a recognized format by World-Wide Web Consortium (W3C). JSON writing and parsing functions are available in all the languages and widely used as a standard language.
Choosing a valid representation format for configuration files is essential as the CCD project depends upon the format used to create a configuration file. The change in the configuration format in the later stage of the project is a difficult and costly affair.
What to Configure?
Once the selection of the format for the configuration file is finalized, the values to be stored are then decided. There are multiple things to consider before you choose the configuration values.
- Common information: The information required for the project from multiple places can be placed in the configuration file. These values are quite stable and need not be changed in the software’s lifetime.
- Default Information: The information representing the out-of-box behavior of the software is added to the configuration file.
- Unstable Information: The information that is unstable or is unknown and depends on the flux during the development time is added into the configuration file.
- Configuration-Dependent Information: These values depend on the other configurations.
Though you can have most of the information configured, the CDD does not allow configuring all the information required by the application. Here are the types of information that are not recommended for configurations.
- Static Information: This information may not be changed in the software’s lifetime.
- Compound Information: These values can be determined using the values added in the configuration files.
- Complex Logic: Values or logic that is handled by the code and usually that depends upon the values of the configuration files.
As the CDD project proceeds, the values for the configuration files are finalized. Once the information that needs to be configured is decided, our developer team decides the storage, representation, and access to these configurations in the code.
How to access the values of configuration files?
In CDD projects, most of the information is accessed from the configuration files. As the project grows these files intend to grow. These conditions make us very choosy in selecting the design patterns for our CDD projects. The patterns and architecture in CDD are scalable and efficient. There are patterns like Singleton, Dependency Injection and Monostate or Borg pattern that can be easily used to uniformly access the configuration information in the projects. But the most used pattern is Abstract Factory that is flexible and harmonizes well with the growing configuration files in CDD architecture.
Things to consider in CDD:
As CDD architecture keeps growing, we need to consider these rules before we create configuration files.
- Keep it simple: The configuration files need to be simple and understandable. Avoid using the syntax that is difficult to read or parse during the runtime.
- Adaptable: As the configuration files will grow for your further needs. While modifying the configuration files, the unused parameters are removed and new once are added. This will keep the files simple and in compact to the requirements.
- Early and Often validation: Often validation of configuration files helps you catch the errors in the development phase. Using the custom validations you can validate the structure of configuration files.
Advantages of Using CDD:
For highly customizable software, implementing CDD architecture offers many benefits.
- Using this technique you can keep your code clean and reduce the duplication. The quality of the product is increased.
- Using a simple format, you can use open-source tools to edit or read these files.
- Abstract and isolates your application with the underlying technology. It provides an interface to the user. The settings in the file can be at the system level, user level or UI and feature level
- Using JSON format for configuration provides course and fine control over your features.
- Avoids compilations of the application, as it is easily reconfigurable at runtime.
Conclusion:
CCD is an invaluable architecture that generates the same application on multiple platforms. It helps to maintain the structure and evolves with the application.
At BundleN, we make sure that your application performs well based on the rules and customizations required on multiple platforms. Though the configuration format is JSON-based, we help you create the custom format of configuration files. The logic for parsing, reading, and editing of configuration files are done by our team.
We look forward to assisting you with your CDD projects. For further information about the projects and process, you can contact us or email us at sales@BundleN.com.[/vc_column_text][/vc_column][/vc_row]