Code Documentation Generation in DDD

1. Background

Currently, the low-code generation field is very popular, and its market value is on the rise. Many giants are heavily investing in this area. The emergence of low-code means that programmers can be freed from repetitive and inefficient labor, allowing them to better support business problem-solving more quickly and significantly enhance the efficiency of delivering value. In DDD (Domain-Driven Design), some people have also attempted to use low-code methods for modeling, aiming to automate the modeling process through templates or predefined scripts. This chapter focuses on discussing the significance of code documentation generation under DDD and what insights this approach can offer us.

2. Perspectives

2.1 Perspective 1—Manual Construction

Many people learning and practicing DDD ask whether low-code tools can reduce the cost of modeling. Some experienced practitioners have explored this, but the results have been mixed. When a sound modeling approach is already in place, building and refining the model manually is often the better choice.

The reason is that DDD involves dynamic adjustments during the modeling process, and the resulting models are not static. Artifacts derived from modeling, such as models, database tables, and API documentation, express business meaning only at a particular point in time. As the system evolves, programmatically generated artifacts can become less useful: models grow stale, APIs become rigid, and changes become more expensive.

Automation also has to keep up with changes across services and projects. Entity models and domains evolve as the business changes, so packages, modules, and interfaces are continually refactored. Code generation can quickly fall behind. Generating artifacts directly from database or entity models may no longer serve current needs as effectively as it did initially, and can drift from the original goal of documenting the domain. Therefore, many experts favor manual construction, where domain experts, product managers, and programmers can gain deeper insights into business.

2.2 Perspective 2: Using Code Generation

Many people in the low-code field have made some attempts, including me, which even earned me a quarterly bonus. However, for most developers to try DDD with low-code is still challenging due to repetitive labor needing engineering solutions. Integrating DDD theory into low-code platforms is not difficult. Core concepts such as domains, subdomains, and contexts can be built to ease the initial understanding of DDD.

One notable work related to code generation is Martin Fowler’s book “Domain-Specific Languages.” It explains how to build a code-generation tool around domain concepts and a domain-specific language. The implementation effort is substantial, however, and may be beyond what most teams can take on.

Of course, this does not mean that DDD code documentation generation cannot be resolved. ContextMapper provides a solution based on Java utility classes and plugin patterns for code generation. The core strategy involves building domain models and entity models based on context diagrams. Many other experts are also exploring DDD-based code documentation generation, but it will take some time to become more mature.

3. Code Generation Products

3.1 UBML

https://gitee.com/ubml/ubml-impl

3.2 ContextMapper

https://developer.aliyun.com/article/771374?utm_content=g_1000251254

3.3 Ctrip Contract System

https://mp.weixin.qq.com/s/4suazm8Z3dheq9jO9g0bjQ

3.4 COLA

COLA is briefly introduced here, where code generation is based on the entire project skeleton, only generating DDD-related package structures. Modeling still requires other methods.

4. What Does Low-Code Mean in DDD?

I use Ctrip’s Contract System as an example to discuss what low-code can offer in a DDD context. Unlike many general-purpose low-code tools, this approach produces domain models, domain documentation, and related diagrams that capture knowledge from a business perspective.

4.1 Engineering Efficiency Improvement

Through the low-code output of DDD, models can be reused and shared. Higher-level domain contexts, subdomains, and context diagrams are also very clear. When developing frontend or back-office systems, teams can trace fields, models, and data flows through domain objects. This makes it easier to integrate new requirements into existing systems and to respond to changes in domains and models. The work is grounded in documented, visualized, and traceable models of both shared and business-line-specific domains.

Reusing a model does not necessarily mean that its domain services can also be reused. A domain may be supported by many microservices, each with its own database. As the business evolves, some services can become rigid and see little traffic. Without a clear inventory of service capabilities, they may remain unnecessary overhead. From a domain perspective, this raises useful questions: are the domains too broadly defined? Can services be consolidated as well as split, and can they provide cohesive capabilities within the domain?

Looking back at Ctrip’s Contract System, it is clearly making the first step in DDD-based code documentation generation and has accumulated some initial business model data.

4.2 Asset Construction

As discussed above, low-code in a DDD context can improve engineering efficiency. Over the longer term, domain models and context relationships can also help us rationalize database schemas and build a body of metadata for analytics. These models can provide a foundation for data platform capabilities, while data analysis can better support business decisions.

4.3 Business Expansion

In terms of business expansion, the main point here is that DDD-based low-code can help us always consider problems from a domain perspective during business development. With existing domain models and documentation, business expansions and adjustments have clear guidelines. During iterative development, we may encounter some issues such as:

1. If an upstream system adds a field, what is the impact downstream, and what if downstream systems need to support it?
2. If several upstream clients integrate with a downstream system, how should model conflicts be handled?
3. Should a new requirement be implemented in a separate library or service?
4. In a collaborative team, which team should own a particular feature or module?
5. How can domain models be extended to support new business capabilities without breaking existing behavior?

These questions are often handled by estimating the changes and effort for each request in isolation. Without a domain perspective, teams can miss the broader effects on business processes, domain services, and models, making it harder to plan and evolve the system coherently.

4.4 Summary

Exploring low-code under DDD may not be particularly interesting, but we can still gain many valuable experiences.