foreword
In Domain-Driven Design (hereinafter referred to as DDD), the user-oriented view layer design is always selectively forgotten in actual design due to the diversity of its implementation methods and its own technical complexity. But today, with the rapid development of low-code technology, DDD has entered the field of low-code with a new attitude. In this section, we will introduce the relevant functions of the OneCode view factory based on the OneCode-dsm domain model.
1. Introduction to View Factory
OneCode View Factory (hereinafter referred to as ViewFactory) is the core component of OneCodeDDD Domain-Driven Design (DSM), and its main design purpose is twofold:
One is for the design model formed by the domain model designer, according to the specific business environment, the decomposition of the view and the merging and binding of domain events are performed, and the final combination is output as a view file compatible with the OneCode designer and as the final project output.
Another design purpose of ViewFactory is to reversely convert the view pages designed by developers through the low-code visual designer through the view factory to generate a "back-end site map" for secondary binding of the domain model or manually write the back-end implementation code.
Second, the operating principle of the view factory
In the domain factory, more anemic basic entity objects are aggregated and sorted to form a hyperemic model that is more conducive to business understanding and operation, and its low-coupling application is realized by extending annotations on its interface model. This style of design is still continued in the view factory to pass ordinary single components, and the aggregation of back-end JAVA codes encapsulates common functions and auxiliary components to form independent view components. The view factory is also an extended annotation based on the OneCode syntax, and the OneCode compiler is finally output as a JSON code that can be recognized by the designer and the front-end framework.
OneCode code conversion example diagram
Simple List Conversion Schematic
form rendering
Three, view factory design purpose
In view design modeling, one of the most confusing questions is, what is the difference between a view designer and a view factory? Why do you need a view factory to model when you have a view designer? The view designer lowers the barrier for developers to get started through visualization. But programming itself is not only a basic skill, but also needs to flexibly use business logic and technical skills, and then distribute them to the actual environment for further training and reconstruction, and finally form the "soul" business & technical architecture of the software.
This puts forward higher technical requirements for low-code view design:
From the perspective of business architecture , we can better understand the business language, such as: automatically matching a view according to the business entity. Automatically update views when business entities change. When the attributes of the business entity change, it automatically matches an input and output method that is more suitable for user interaction, such as: warning information display, red for serious, yellow for warning, green for normal, etc. These applicable designs in DDD use domain events to match corresponding business domain value objects to realize the construction of a general model.
domain building model
In fact, there has always been a controversy in terms of technical architecture, that is, whether architecture is priority or implementation is priority. An excellent architecture will bring excellent technical experience in many aspects such as system robustness and scalability . But redundant design from the beginning is also rejected by many projects. In the field of low-code, there is also the idea of "middle platform, micro-service" and then building low-code applications, but in practice, these are technical requirements that are difficult for ordinary users to meet.
The designer builds the model
View Factory (ViewFactory) is designed to balance the intermediate fusion of these two modes. In the view factory application, it is allowed to develop parallel development in two ways at the same time, and realize the conversion between the two by adjusting the properties of the configuration tool. And unified into the DDD model to achieve continuous integration.
4. Overview of view factory function design
(1) Module aggregation
On the basis of common fine-grained components, the view factory provides a complete view encapsulation path to realize high-aggregate configuration applications at the module level.
aggregation function
Page aggregation sample display
@PageBar
@GridAnnotation(event = CustomGridEvent.editor,
customService = IPersonAPI.class,
customMenu = {GridMenu.Add, GridMenu.Delete, GridMenu.Reload})
public interface IPersonGrid {
@CustomAnnotation(pid = true, hidden = true)
public String getPersonId();
@CustomAnnotation(pid = true, hidden = true)
public String getRoleId();
@CustomAnnotation(pid = true, hidden = true)
public String getOrgId();
@CustomAnnotation(caption = "邮箱")
public String getEmail();
@CustomAnnotation(caption = "账户信息", required = true)
public String getAccount();
@InputAnnotation(inputType = InputType.password)
@CustomAnnotation(caption = "密码", required = true)
public String getPassword();
@CustomAnnotation(pid = true, hidden = true)
public String getName();
@ComboNumberAnnotation
@CustomAnnotation(caption = "手机")
public String getMobile();
@CustomAnnotation(caption = "部门名称")
public String getOrgName();
}
(2) Overview of aggregated views
(3) Aggregation configuration configuration overview
(4) Commonly used view annotations
| Annotation name | view type | example |
|---|---|---|
| @FormAnnotation | form view | @FormAnnotation(customMenu = {CustomFormMenu.Save, CustomFormMenu.Close}, customService = ColService.class) |
| @GridAnnotation | list view | @GridAnnotation(rowHeight = "4em", customMenu = {GridMenu.Reload, GridMenu.Add, GridMenu.Delete}, customService = {LocalFormulaService.class}, event = CustomGridEvent.editor) |
| @TreeAnnotation | tree view | @TreeAnnotation(heplBar = true, caption = "Select Person", selMode = SelModeType.singlecheckbox) |
| @NavTreeAnnotation | tree navigation view | @NavTreeAnnotation(bottombarMenu = {CustomFormMenu.Save, CustomFormMenu.Close}, customService = AggWebSiteSelectService.class) |
| @GalleryAnnotation | Text list view | @GalleryAnnotation(customMenu = {GridMenu.Reload, GridMenu.Add, GridMenu.Delete}) |
| @TabsAnnotation | Tab page view | @TabsAnnotation(singleOpen = true) |
| @ButtonViewsAnnotation | button group navigation | @ButtonViewsAnnotation(barLocation = BarLocationType.left, barVAlign = VAlignType.top, autoReload = false) |
| @NavGroupAnnotation | group container view | @NavGroupAnnotation(bottombarMenu = {CustomFormMenu.Save, CustomFormMenu.Close}) |
| @NavGalleryAnnotation | card navigation | @NavGalleryAnnotation |
| @NavFoldingAnnotation | folding page navigation | @NavFoldingAnnotation(bottombarMenu = CustomFormMenu.Close) |
| @NavMenuBarAnnotation | menu page navigation | @NavMenuBarAnnotation |
V. Instructions for subsequent chapters
The view part is the most used part by developers, and it is also a link with a relatively large amount of content information. In the subsequent DDD chapters, we will introduce a view in each chapter independently, and synchronize the sample code with the running project Published in the open source community.