This repository contains all the materials you need to quickly build a new development environment.
The development of this project relies on container technology and requires a Docker environment. If you have not configured Docker environment, please configure Docker environment by yourself first. for Mac OS X and Windows, please install Docker Desktop, for Linux system, please install Docker CE directly. the following information is for reference.
- Mac OS X: https://www.docker.com/products/docker-desktop
- Windows: https://www.docker.com/products/docker-desktop
- Ubuntu: https://docs.docker.com/engine/install/ubuntu/
- CentOS: https://docs.docker.com/engine/install/centos/
The frontend dependencies installation depends on npm and yarn. If you have not installed npm and yarn, please install npm and yarn first.
This project uses a mix of Java and Kotlin development, heavily dependent on the Java ecosystem. Please install OpenJDK 17 first.
-
OpenJDK 17 for Windows:
-
OpenJDK 17 for Mac:
-
OpenJDK 17 for Linux:
For a better development experience and more efficient development, please use IntelliJ IDEA as the default development tool: IntelliJ IDEA:
- IntelliJ IDEA: https://www.jetbrains.com/idea/
All dependency services for this project can be built in an automated way. You will need to write your dependency service deployment scripts. To build a completely new environment, execute the following command in the project root directory.
sh ./scripts/setup-local./gradlew npm_installIn order to maintain the quality baseline and provide the necessary foundation for continuous integration, the project provides the necessary infrastructure, one of which is the quality gatekeeper.
The quality gatekeeper provides various quality checks such as static code checks, unit tests, integration tests, test coverage, front-end tests, etc. Developers must perform quality gatekeeper checks locally before each code push to the code repository, and the build server will also trigger quality gatekeeper after the code is pushed to the code repository. Execute quality checks locally by directly executing the following commands.
sh ./scripts/check-all./gradlew bootRun./gradlew yarn_start./gradlew :qomolangma.webui:yarn_build./gradlew :qomolangma.webui:yarn_testsh ./scripts/build-allIn contrast to traditional development frameworks, we use a neat architecture as the guiding framework for our projects, and implement Test Driven Development (TDD) + Domain Driven Design (DDD).
https://medium.com/@matiasvarela/hexagonal-architecture-in-go-cfd4e436faa3
https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
. /src. /frameworks. /modules. /scripts. /frontendsTest Driven Development is the best way to develop high quality software, for more theory on TDD please refer yourself to the web literature. https://en.wikipedia.org/wiki/Test-driven_development
https://www.oreilly.com/library/view/modern-c-programming/9781941222423/f_0055.html
The project strictly follows the TDD principle. Since testing comes first, the business code should have relative response tests for each kind of path, in this case, any uncovered code is redundant, so the project has extremely high requirements for code coverage, and must ensure 100% code coverage.
- Integration testing should be done in
. /src/test/{kotlin:java}/... /usecases/{corresponding domain}/. - Integration tests need to inherit from
IntegrationTest, and if api is involved, it needs to inherit fromApiTest. - unit tests should be written in the corresponding module
Domain-driven design is the core solution for complex software. The project practices domain-driven design, and it is recommended to develop in accordance with it.
Core layer, no third-party dependencies allowed, only the cleanest business code is kept.
Use case layer, a scenario corresponds to a UseCase, UseCase only allows to call objects in the domain layer, by the object to carry out its own corresponding behavior.
The gateway layer, where any third-party calls are implemented, is abstracted by the dependency inversion technique into the interface of the domain layer.
- Only the dependencies shown are allowed (gateways depends on application depends on domain for the same domain, domain depends on core and gateways depends on application for different domains), any other dependencies are forbidden.
- modules can depend on the corresponding frameworks domain.
- Prohibit the introduction of any third-party dependencies in the domain layer and application layer, third-party dependencies are only allowed to be referenced in gateways, and dependencies are inverted using the Adaptor idea when the domain is used.
- Prohibit annotations, methods are annotations, and the code corresponds to different tests that are different use cases.
. /gradle/libs.versions.tomlProject integration with restdocs, api documentation needs to be maintained in the test
Use payload as api context object to eliminate redundant, cumbersome Input, Output(vo, dto).