System Design

We’ve successfully deployed a service and confirmed that its accessible. However, a single service doesn’t make an app. We now need to fill out the rest of the application and introduce some best practices around service governance and system engineering.

The Application Design

We’re going to be organizing the UI as microUI applications that interact directly with services specific to their function. This will give us flexibility in terms of evolving our enterprise application functionality. Additionally, each service will publish a message reflecting a change to the state of the data maintained by that service.

We will be able to move between UI application contexts because we’ll be using OAuth and will configure our application to recognize the token across contexts.

First Steps

We’re going to be using our initial service as a template for the new development. However, even though we’ve done a lot of work here to get it into a ‘good’ place, there are still some gaps that we’ll want to patch before we use it as a good example.

Validate Customer Existence

We knew that we are not handling duplicate customer creation requests consistently across platforms (different databases handle the request differently). We want to manage this better with this flow:

Return Existing Customers

We probably also want the ability to return a single user as well as a list of all users. So we want to add these flows as well:

Implementing all of this should be fairly straightforward based on our current codebase. The only thing that is unique is the updates to CustomerDAO:

Optional<CustomerEntity> findByEmail(String email);

This is spring’s JPA convention. By using their method naming convention spring can generate the JPQL for you.