How to start a JUDO project?

Toolbox models:

• Entity Model (acting as an ORM abstracting away the persistence layer)

• Transfer Model (Work In Progress)

• Service Model (2023 Q1)

• Frontend Model (2023 Q2)

• Action Script (2023 Q3)
  
  

We explain these models/layers on our website: https://judo.codes.

Based on historical experience, we realized that previously imagined development practices do not always fit our use cases. Hence, we changed our approach to focus on a DSL-based modeling paradigm instead of a graphical designer tool.

Benefits of DSL modeling over visual editors:

• Models are easier to maintain in a text form:

  • It is easier to navigate and search in our models

  • with the added benefit of quick edit capabilities with IntelliSense support from IDEs etc.)

• Models are easier to store, share, and diff in version control systems

• If developers are using supported IDE-s, we can provide diagram drawing capabilities for DSL-based models
  
  

You can find documentation for our DSL on our official page: https://documentation.judo.technology

Every Toolbox model/layer refers to DSL features with corresponding SDK / code generators and runtimes which can be used separately or combined to deliver applications.

System Requirements:

To use the JUDO Toolbox, we need to ensure that our system meets the following minimal requirements:

• JDK 11 (JUDO is currently tested and developed with Zulu JDK) 

• Maven 3.8.x (https://maven.apache.org/download.cgi)
  
  

Bootstrap a Spring Boot project:

Generating a test application

Now that we have a basic understanding of what JUDO is, we can bootstrap a fully operational Spring Boot project with JUDO DSL support.

Open your terminal and go to a folder where you would like the archetype to generate your project (e.g., ~/projects/).

Running the following command generates a Spring Boot project with a test model and a simple integration test:

mvn org.apache.maven.plugins:maven-archetype-plugin:3.1.1:generate -B \

  -DarchetypeGroupId=hu.blackbelt.judo.jsl \

  -DarchetypeArtifactId=judo-jsl-springboot-archetype \

  -DarchetypeVersion=1.0.4 \

  -DgroupId=com.example \

  -DartifactId=test \

  -DmodelName=Test

Once the archetype has finished generating sources, our project should be available under ~/projects/test.

Running mvn clean install under our project will also run the build and tests. If you have changed nothing, the process should finish with no errors.

Generated sources explained:

We could consider the generated project a stock Spring Boot Starter-based project with added JUDO SDK generation capabilities based on JUDO DSL-based models.

Because of this nature, we will only explain the most interesting/important files.

application.yml

Located under: src/main/resources

The application.yml file is a standard Spring Boot configuration file with one addition, which is the “judo” section. Currently, this section contains the “modelName” property which points to our entry point model.

Test.jsl

Located under: src/main/resources/model

The Test.jsl file is our model entry point. The generated model should look like this:

model Test;

type string String(min-size = 0, max-size = 128);

entity Person {

    field String firstName;

    field String lastName;

    derived String fullName => self.firstName + " " + self.lastName;

}

To have a better understanding of the capabilities of our modeling language, please consult the corresponding section in our documentation!

TestApplicationTests.java

Located under: src/test/java/com/example/test

By default, our archetype generates a simple test class that can better understand / experiment with the generated SDK.

One key concept here is that we rarely (if never) need to import or think about the actual implementation code regarding our SDK. Most of the time, we only need to import interfaces and we should be ready to use them.

The generated test code should look like this:

package com.example.test;

import com.example.test.test.sdk.test.test.Person;

import org.junit.jupiter.api.Test;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.boot.test.context.SpringBootTest;

import java.util.Optional;

import static org.junit.jupiter.api.Assertions.assertEquals;

@SpringBootTest

class TestApplicationTests {

    @Autowired

    Person.PersonDao personDao;

    @Test

    void testDaoFunctions() {

        Person createdPerson = personDao.create(Person.builder()

                .withFirstName("FirstName")

                .withLastName("LastName")

                .build());

        assertEquals(Optional.of("FirstName"), createdPerson.getFirstName());

        assertEquals(Optional.of("LastName"), createdPerson.getLastName());

        // Test derived

        assertEquals(Optional.of("FirstName LastName"), createdPerson.getFullName());

    }

}

Conclusion:

Based on the model and test above, it is worth highlighting that:

• We are generating builders for every entity (e.g.: Person) and almost if not all query parameters to improve the developer experience.

• Based on our model, where we defined a “derived” member called “fullName” the createdPerson instance contains the concatenated value after retrieval.

The JUDO DSL language contains many powerful features which should enable developers to speed up development by abstracting away the cumbersome manual implementation of complicated business rules or data modeling concepts.

For further information, please check the “Modeling Language” section of our documentation!