Modeling entities in JDL 

Since we have already used the JDL studio when we were setting up our monolithic application, it's time to update it. 

As discussed in the previous chapter, we will move the entities from a monolithic application to a gateway application, then, remove the invoice-related entities from the monolithic application, use them in our invoice microservice, and then update the related invoice references in that. Finally, we create entities for the notification microservice. 

The following diagram shows our new JDL entity model: 

The invoice is a perfect candidate to move out into a separate service. We can completely decouple invoice and its dependencies, but this will cause one problem in our current application—the ProductOrder entity is related to the Invoice table and we have to remove this dependency while keeping the relationship (but not as a foreign key) as an indirect key in ProductOrder that connects with the Invoice entity.

This can be achieved in two ways. We can change the foreign key into just another column in the ProductOrder entity, or create another entity called InvoiceOrder that just holds InvoiceIDs and ProductOrder IDs and map it to the ProductOrder entity.

The former keeps the table structure more or less the same and allows easier migration. The latter will increase isolation at the cost of normalization, and they are heavily used in high-performance applications. As you see, both have their own merits and demerits. The approach you should take depends purely on your requirement. We will consider the first approach.

As a first step, we will remove the relationship from Product owner in JDL defined in online-store.jh as shown for:

relationship OneToMany {
     ...
     ProductOrder{invoice} to Invoice{order},
     ...
}

Remove the highlighted line and move all the invoice-related entities to the invoice-jdl.jh file.

Then, go to the Product Order entity, add an invoiceId field, and mark it as the Long type. It is an optional field and hence doesn't need the required keyword:

entity ProductOrder {
    placedDate Instant required
    status OrderStatus required
    invoiceId Long
    code String required
}

Entities for microservices can be tagged using the microservice keyword supported by JDL. This helps JHipster to identify entities that belong to a specific microservice. It follows the same JDL options syntax that we saw earlier:

<OPTION> <ENTITIES | * | all> [with <VALUE>] [except <ENTITIES>]

• microservice keyword
• Followed by the names of the entity, comma separated if multiple
• Followed by the with keyword
• Followed by the name of the microservice

We should use different files for microservices' entities, so that we create two files, invoice-jdl.jh and notification-jdl.jh, that contain the entities related to invoice and notification respectively, along with the original.

Then, we map the existing Invoice entity to the microservice in our JDL:

microservice Invoice, Shipment with Invoice
entity Invoice {
    date Instant required
    details String
    status InvoiceStatus required
    paymentMethod PaymentMethod required
    paymentDate Instant required
    paymentAmount BigDecimal required
}

enum InvoiceStatus {
    PAID, ISSUED, CANCELLED
}

entity Shipment {
    trackingCode String
    date Instant required
    details String
}

enum PaymentMethod {
    CREDIT_CARD, CASH_ON_DELIVERY, PAYPAL
}

relationship OneToMany {
    Invoice{shipment} to Shipment{invoice}
}

service * with serviceClass
paginate Invoice, Shipment with pagination
microservice * with invoice

Then, it is time to create another JDL file to hold the notification service details. Create a file called notification-jdl.jh and add the entities for notifications into it:

entity Notification {
    date Instant required
    details String
    sentDate Instant required
    format NotificationType required
    userId Long required
    productId Long required
}

enum NotificationType {
    EMAIL, SMS, PARCEL
}

Then, we bind these entities to the Notification microservice, with the following:

microservice * with notification

That is it. We have defined the domain model for our microservices.