Application modularization, encapsulation, and naming for better reuse and maintenance
Application modularization, encapsulation, and naming for better reuse and maintenance
| Application modularization, encapsulation, and naming for better reuse and maintenance | |
|---|---|
| New URL | https://docs.pega.com/bundle/platform-88/page/platform/app-dev/application-modularization-encapsulation.html |
| This article has been moved over to our Pega Community here in order to align with our larger content strategy. Please update any bookmarks or links that you may have to this location. | |
Writing large monolithic applications, enjoy general bias from the developers, as these can be tailored to fit the use cases and be coded faster. The benefits of this choice however are often short-lived, as these monolithic applications are incredibly difficult to maintain and debug, owing to their sheer size and tight coupling. Additionally, large portions of these monolithic applications must be duplicated in many parts of the application that share a similar function. Thus, further adding to the maintenance costs, as any changes to one routine would have be repeated to a bouquet of other similar routines.
One of the basic design choices here would be to identify the discrete functions that are required to build a feature and encapsulate the associated logic into smaller appropriately named granular modules, that have clearly defined interfaces for input and output. These modules or even modules made of smaller modules can then be stitched together to create a neat loosely coupled application.
This design choice though very basic, brings in huge advantages, such as:
- Reusability: As these modules essentially follow a headless approach with well-defined interfaces, these can be used to cater to more than one feature in your application or even across applications.
- Maintenance: Any bugs and issues can be easily isolated and fixed within a module. Since the fixes are limited to modules, the impact analysis required and the regression issues introduced are drastically reduced, provided that the input and the output of the module is maintained. What is even better is that the fixes once made need not be repeated in any other part of the application. Same is true for any enhancements that are required to be made to a given module.
- Readability: Each module has only one function to accomplish, the code is hence easier to read and follow.
- Testing: Instead of just testing the feature end to end, developers can focus on each module individually and targeted tests can be executed for each module. Based on the size of the module, the tests could be as elaborate as functional tests or as basic and strict as rule based automated unit tests.
- Collaboration: Instead of building a feature of a substantial size, developers can focus and build smaller modules independently, and then stich them together to build a multitude of different features in your application. Thus, promoting collaboration and fast paced development results in shorter and more efficient development cycles.
- Independent Releases: Owing to modularization, an application can be released as soon as the basic application features are ready, and more modules can be further added with little to no changes to the existing modules.
Though modularization requires careful thinking and design which may take time, but the time is well invested owing to the long term benefits that it brings in leading to a drastically reduced cost of ownership.
Use case examples
Modularization can be realized in an application at a level as fundamental as that of the activities and data transforms or as abstract as application, rulesets, and case types. Consider the following examples:
Example 1: Consider an onboarding application that must connect to an external system to verify the customer data, and then proceed with or abandon the onboarding. This interface to connect with the external system can be built directly within the application and its rulesets. However, if in the future a similar need arises in the institutions that use an insurance application, the whole interface will need to be rewritten for the new application.
It is more efficient to modularize the interface and build it in separate rulesets or as components. These components/rulesets can then be included in both the applications, or even more applications as required, and the desired integration with the external system can be achieved without the need to rewrite the interface.
Example 2: Consider a review case where a customer record must be fetched form the database for a given customer ID. The data must then be evaluated to determine the customer risk and appropriate due diligence questionnaires must be applied to the case based on the derived risk. Though this use case can be simply implemented by writing everything within one activity/data transform, each of these actions may be used in different contexts throughout the life cycle of the case. For example, the risk evaluation may be performed on the customer data after the data is amended through the user interface to determine a change in the initial and final risk.
This use case warrants modularization into three separate routines: a data page for fetching the customer record and two data transforms - one for determining the customer risk and other for applying due diligence questionnaires. These routines can then be stitched together into a final data transform to fulfill the use case.
Before you begin
Modularization, if overdone can increase the code size and affect the performance of your application. You must hence consider the following key points before you choose to modularize the code:
- The modules must be reusable. Research any present or future use cases where the module can be applied.
- Every small function in your application does not require to be a module. For example, setting up a property by copying an input parameter need not to be a module.
- If it is a small one-off application that will not be maintained or extended in the future, it may be better to avoid modularization in favor of faster implementation.
- Modularization can also be a good choice when you have a large team that must collaborate and build the application, provided that the application can be functionally and technically divided into smaller modules.
Process to achieve objective
Modularization options in Pega Platform™ are conceptually limitless and every single rule within Pega Platform can be achieved at various levels and in various ways. Consider the following general guidelines while modularizing your code:
- When designing the architecture of your application, determine if the features that you plan to build for your application are reusable, and then create separate applications, components, or rulesets if they are.
- Consider breaking down each routine into sizable smaller modules that have well-defined input and output. The routine may be a case type, stage, process, data page, activity, when rule, or any other rule form.
- Consider interoperability between modules. Each module must be self-sufficient and to the extent possible communication with other routines, each module should use only in and out parameters.
- Do not create modules for absolutely every small thing. Creating unnecessary modules will be counterproductive, which will increase maintenance costs and potentially also result in performance issues.
- Name a module appropriately to represent the function that it performs. It is also a good idea to key in a brief description of what the module does, in the usage field. This will make the code easily locatable and promote reuse.
- Educate your team on modularization and encourage them to reuse rather than rewrite code.
Results
Implementing modularization will provide a greater degree of reuse and maintainability as the modules for each function are centralized and can be easily reused, tested, updated, or even replaced to propagate the changes to all the features that use these modules. Thus, crushing the complexity by a big margin.
Related information
Designing applications for reuse and extension