prefaceIn low code platforms, if complex models need to be supported, module level source code export functionality is often required. Independent modules can be exported as independent running native code for further integration with industry systems

preface

In low code platforms, if complex models need to be supported, module level source code export functionality is often required. Independent modules can be exported as independent running native code for further integration with industry systems. In today's relatively mature low code platforms, this feature has also become a necessary feature for the vast majority of commercial enterprise level low code platforms. This article will discuss the code export design of low code platforms from the perspective of module code export.

After the user completes the basic view design and application logic orchestration, it is usually necessary to convert the business design into executable code and configuration in a specific way for simulation testing or direct delivery and deployment of the application. There are usually several ways to do this:

(1) Template mode (directly output code as executable native code)

Long before the birth of low code related technologies, code generation patterns were popular in the architecture design community. The architect shall establish the Technology roadmap and code structure, generate the basic code in batches from the database or general configuration through the template language such as framake, and then submit it to the programmer for secondary processing.

The advantages of this approach are:

Easy to operate, a slightly experienced senior programmer can complete the entire basic template design, which can greatly reduce the labor intensity of ordinary programmers after template output.

But the drawbacks are also obvious:

Firstly, due to the oversimplification of the model design process and the lack of metadata and meta data attribute support, when higher level attribute support is needed during code generation, it can only be enriched in the template. This leads to severe contamination of the code template and greatly reduces its universality. In real use, there is often a dilemma of one project per template, and even a programmer having their own set of templates. This significantly reduces the maintainability of the project, and in most cases, after the code is generated, some secondary supplementation and modifications are needed. These processes are usually irreversible, which makes code generation can only be used when the project is initially built, and cannot play its due role in function extension or Code refactoring.

Summary:

The pure code generation mode, if used purely as a programmer or micro project team, is still acceptable as a code tool and is commonly used in various industry templates and other applications in early low code platforms. However, with technological progress, this method is gradually being phased out.

(2) Engine driven mode (output code is DSL)

The engine driven pattern originated from "middleware" design, which aimed to abstract and package a large number of business logic with universal significance, provide independent data models, and then abstract specific DSL business description languages based on business characteristics, such as process language BPEL, extended EXECL formulas in reports, SQL language in databases, and so on. Users use DSL language to describe business structures and data information, and then entrust DSL to the engine for execution, effectively achieving decoupling between business and code. This technology is widely used in low code platforms, and is even more standard in enterprise level low code platform applications.

Structural composition

Implementation process of code output

Advantages of engine mode:

The engine mode is to output the business model to "DSL", a Intermediate representation. This mode solves the secondary maintenance and reversible output of the model well. It is also relatively perfect in terms of general functions and technical details, which can bring a better sense of use to direct users. It also has a good performance in project reconstruction and later maintenance.

Disadvantages of engine mode:

(1) Lack of usability and high technical requirements for users:

The engine mode has many advantages, but in low code platforms, in addition to strong functional and scalability support, it also needs to consider its usability. For core users of low code platforms, they are mainly positioned as pan developers rather than expert programmers. The design of multiple engines will become more segmented, powerful, and require a wider range of professional fields for developers. The requirements for integrated secondary development will also become increasingly strong. Although the original intention of the middle platform mode and APAAS platform advocated under the multi engine mode is to better decouple applications and realize Microservices architecture. But to some extent, it runs counter to the positioning of low code platforms as pan developers. Often in enterprise applications, once a central platform is established, APAAS applications become the existence of giants, resulting in a lack of business flexibility and a rigid technical architecture.

(2) The construction process is complex and not suitable for simple applications

In engine mode, business function splitting is relatively detailed, which is beneficial for building complex applications. However, in daily enterprise application development, most application functions are often similar to small functions such as "experimental data reporting" and "instrument and equipment management" that are only used in relatively closed environments. For this simple application, the engine's functionality may appear too powerful. The implicit rules and design requirements contained in it make it difficult for ordinary developers to follow.

(3) Difficulty in engine expansion

Business applications are often complex and ever-changing, and the requirements for engines can vary. Sometimes, powerful functionality and business practicality are two concepts. Relying solely on infinite expansion of engine functions to avoid intrusion of business code into the engine can sometimes backfire. The appropriate extension API allows developers to conduct deep call development, which is the strategy of most engines. But it is not easy to use this strategy well, as developers need to have a considerable level of proficiency in engine structure. This often becomes the biggest obstacle in engine mode.

(3) DDD domain driven design (code output is DDD domain design driven language)

The concept of Domain Driven Design (DDD) is derived from Eric Evans, a renowned modeling expert, who published his most influential book in 2004: "Domain Driven Design Tackling Complexity in the Heart of Software", also known as Evans DDD. In DDD, it covers business requirement decomposition methods, project engineering management methods, and its application through repositories The Domain model and other concepts are defined to achieve the design purpose of high aggregation and low coupling.

Domain driven design, as the basic theoretical model of Software architecture design in the early stage, is a theoretical compulsory course for architects. However, in low code applications, low code tools based on DDD driven design models allow ordinary developers to design excellent software works. This makes supporting the DDD theoretical model a benchmark for the next generation of low code platform theory. The emergence of a series of Domain model tools has also significantly reduced the threshold of domain driven design.

Domain modeling model:

Advantages of DDD domain driven mode:

(1) Unified model support for simple business and complex engine business

Domain driven mode is an enhanced version of code generation and engine mode. The functions of each engine in the domain driven model are packaged and described at a higher level through Domain model such as general domain and support domain. Developers no longer focus on independent engine APIs to complete development, but use unified domain tools to complete configuration applications in domain services and domain events. Simple and single business models can also build composite Domain model aggregation entity libraries through warehousing templates, and finally be unified into independent user-defined user domain services. Developers can organically link the two when based on the Domain model. To facilitate the separation of business logic and specific implementation. The unified language environment support allows domain services to directly touch the DSL rules of each engine, facilitating the organic completion of collaborative work among various engines in domain events.

(2) Modeling high aggregation applications centered around business applications

The domain modeling design concept is based on a specific "business model", and its corresponding output code is also directly executable business code. This is thanks to its high aggregation design, but it also provides strong modeling theoretical and technical support for the transition from low code platforms to no code.

(3) Low coupling design between modules

DDD domain driven design not only emphasizes business leadership, but also pays more attention to the metadata surrounding the business entity process and data, as well as the support of meta meta data. In addition to the main business, metadata and meta meta data models are used to describe the events, actions, interactive presentations, and so on associated with the business source itself. This makes the isolation of the business itself better, and the correlation between business modules clearer. When designing business associations and implementing them, only the associations of the business itself need to be concerned, while for other events, presentation interactions and other unified metadata and meta data processing are used to achieve decoupling applications.

Meta data configuration

Disadvantages of DDD domain driven mode:

Domain driven design is highly abstract and isolates business implementations, but it serves as a new design pattern. The corresponding tools and developer ecosystem are relatively scarce. For most business modules that have already been integrated through native code and business models based on engine DSL language, the stripping of metadata and meta data still needs time.

OneCode low code engine is a universal low code engine designed based on DDD driver. OneCode adopts JAVA as the native language and implements a complete universal domain driven metadata model through Java metadata annotation. It also provides complete configuration management and metadata export design for metadata of Domain model and metadata supporting metadata application. Developers only need to introduce OneCode metadata annotation package and add corresponding metadata annotation to render and output to Domain model applications through OneCode low code engine.

(1) OneCode metadata annotation

(2) OneCode metadata annotation can be read for visual editing

(3) Metadata design of general Domain model

(4) Page Designer

Disclaimer: The content of this article is sourced from the internet. The copyright of the text, images, and other materials belongs to the original author. The platform reprints the materials for the purpose of conveying more information. The content of the article is for reference and learning only, and should not be used for commercial purposes. If it infringes on your legitimate rights and interests, please contact us promptly and we will handle it as soon as possible! We respect copyright and are committed to protecting it. Thank you for sharing.(Email:[email protected])