Customizable enterprise systems

It's quite common for solutions for enterprise companies to purchase 3rd party software packages that need heavy customization. Each enterprise is unique and often requires custom domain model changes, and frequently requires integrations that might not be already exist. The code might be performed during a services engagement and remain for years untouched until the 3rd party package is upgraded. It's likely that some files copied and modified during the original project have been changed by the vendor in the meantime so to apply the update, someone needs to make a careful merge of the changes.

Once those files have been identified, diffs might be able to patch it automatically, or maybe it's an obvious change. In some cases though, it might be tricky even if you had the two developers in the room who made the conflicting changes and that's why everyone is reluctant to upgrade certain enterprise software.

With layers, programmers do less copying to implement customizations in the first place. Secondly, enterprise software vendors have more flexibility for adding new features in new layers letting them offer more highly customized packages from the start. It's easier for the vendor to test more of their customer's configurations, and possibly even own and manage the customer's customizations as part of their code base.

Separating application code from framework code

Most of the time, enterprises need to customize the business logic of their application. It's their domain model, database, or some set of integrations that's different which modifies or uses the domain model. Custom fields, custom reports, changing a query, or customizing a form's UI. But when they apply the domain model customizations, they end up writing framework specific code as well. That's because today's enterprise frameworks tend not to completely separate framework code from the application code that's specific to the business. Even the most modern application frameworks do not do a good job of separating application code from framework code. Frameworks like JPA, Spring and hibernate tie your domain model code to their framework code. Or your models are glued to some XML format that ties you to framework code at runtime. Features like configuration, transactions, caching, leak into application types with dependencies when they should be cleanly separated from the domain logic code. When framework dependencies are added to the domain model code, not only do you increase the risk of having to replicate or change domain model logic in response to changes in the framework, you also have a much harder time with domain model customizations because they become more complicated.

And over time frameworks change and evolve as the IT landscape evolves. New features and platforms are in demand: real time, mobile, better transparency, better performance, etc. Separating framework from domain logic will let you reuse that logic with current and future platforms. Logic running on the server today, may need to run on a mobile device tomorrow. Spring and Hibernate may never be suitable technologies for the mobile platform. The real question is not how to tune spring and hibernate but how you properly tease apart the dependencies on such systems from the code you really care about - the part that defines how your business runs.

StrataCode's design provides the basic structure to separate dependencies in code naturally, without complex code refactoring. Start by taking your large existing code base and importing it as one layer. Break apart the domain model into a clean set of sub-layers which compile into the same basic application, piece by piece. Incrementally evolve an architecture even from a giant monolithic system, separating the domain model from your frameworks. Start building new framework layers to modernize your applications.

Once a developer learns the tricks to use layers to separate code based on dependencies, designs become cleaner and easier to read by separating concerns. Developers eliminate needless code copies, wrappers and other boilerplate making domain model changes faster. Large classes are split into pieces based on the role of the code in the project (e.g. database, UI). This organization typically aligns with developer responsibilities, reducing conflicts among team members.