In this article, we will discuss if a low-code platform could be flexible enough to describe the logic of really sophisticated business processes.
Low-code is a business application development method that involves assembling ready-made framework components into business systems while minimizing scripting.
This approach has proven useful for providing solutions for standard business tasks, wherein the developers of a low-code platform itself predicted the required functionality in advance. For example, every function in a CRM application can indeed be implemented without writing a single line of code.
In real life, however, businesses tend to have their unique requirements that go beyond the scope of low-code platforms. Thus we face the inability to adapt low-code based solutions to specific business logic fully. Are there any ways to solve this problem without giving up the advantages of low-code?
Everything depends on the frameworkGiven the limitations noted above, conventional wisdom holds that more complex calculations or algorithms require resorting to programming in a low-level language. For example, many developers of accounting systems would say that cost calculation for complex products — or processing payroll that may be affected by dozens of factors — calls for “putting on some finishing touches in C++” or another programming language. It means having to engage experienced coders, as well as maintain custom integration interfaces.
Conventional wisdom notwithstanding, low-code solutions for complex business tasks are both possible and widely used. All that’s required is that the development platform allows profound modification to the algorithms that determine how its built-in objects function. It would enable developers to implement business logic for scenarios of any conceivable complexity without resorting to low-level programming.
Domain-Driven DesignThis problem, which is characteristic of all business development, led to the creation of Domain-Driven Design (DDD). DDD involves the creation of optimal abstractions and closed systems of objects that make up the real-world subject area (domain) model. A DDD-oriented development framework has to have at its core a range of templates (objects) and interactions that are specific to the domain it will be applied in. Thanks to this, developers that use such a framework can operate with ready-made classes to develop the final product. The logic of the code has to correspond with the real-world subject area. This correspondence is due to a unified language used by both domain experts and developers. Within Domain-Driven Design, this is called the Ubiquitous Language.
Domain experts are the people who understand how the business processes that the developers have to model work. They may be analysts, managers, or executives.
On the other side of the equation are developers and architects who are directly involved in implementing applications and automation and might not understand business processes as such.
The constant interaction between domain experts and developers is needed to synchronize, agree on goals, and plan the development process. This interaction uses the Ubiquitous Language to avoid ambiguity and miscommunication.
All artifacts are, as much as possible, described using the terms of the Ubiquitous Language, starting with the project requirements and ending with the code.
So, how DDD relates to the low-code customization flexibility?Concepts from the world of traditional development — classes, database tables, servers, libraries — are moved “under the hood” of the framework. The developer works with platform objects reflecting business logic — catalogs, documents, registers (ledgers), charts of accounts, etc.
The developer selects from a reasonably limited set of ready-made classes and sets the properties of the classes in a visual editor. Thus, the developer “tells” the platform what the application will be — what entities it will contain, what the relationships between them will be. The platform itself then creates the database structure, reads/writes to the database, and draws the default user interface.
However, coding, as such, cannot be entirely excluded in cases when you can not predict business logic. For example, calculating taxes after legislative changes, actual cost calculation, discounts, etc.
In the case of the 1C:Enterprise platform, the application of DDD principles extends to the built-in 1C programming language. It is a Domain Specific Language (DSL) that allows the use of business-specific logic. Simple expressions in 1C language enable developers to manipulate objects specific to accounting, such as documents, catalogs, and reports, abstracting as much as possible from DBMS- and OS-level coding.
Even without specializing in spheres like financial audit or accounting, a software developer can use a unified data model and ready-made accounting templates to design an application.
Thanks to the ready-made templates, there is no need to invent anything or program “from scratch.” At the same time, there are no hard limits on the system’s functionality, due to the ability of the built-in DSL to modify the algorithms underlying the templates’ functions. For example, you can implement complex calculation mechanisms without connecting third-party solutions and programming languages.
Thus developers don’t have to sacrifice customization flexibility and scope of their applications using low-code.
The article was originally published at: https://medium.com/1c-developer/low-code-limits-customization-flexibility-myth-or-reality-ea64727083...