Matthew M Dalby
Articles / ERP Demo / Establishing the initial project setup
Icon

Establishing the initial project setup

Let's deep dive into how to create a foundation for a the projects.

Project structure

Keeping in mind that we are creating dual implementations for the API components, this doubles the projects related to the API backend. The projects will be as follows.

erp-api-entity-mgmnt-javaAPI used for manging core entities (Java)
erp-api-entity-mgmnt-javaAPI used for manging core entities (Node)
erp-api-inventory-nodeAPI responsible for inventory tracking and calculations. Also includes a messaging client to support asyc operations. (Java)
erp-api-inventory-javaAPI responsible for inventory tracking and calculations. Also includes a messaging client to support asyc operations. (Node)
erp-api-work-order-nodeAPI dedicated for supporting work order operations (Java)
erp-api-work-order-javaAPI dedicated for supporting work order operations (Node)
erp-core-javaCommon functions (Java)
erp-core-nodeCommon functions (Node)
erp-ui-entity-mgmntReact front end used for managing basic data
erp-ui-tank-boardReact front end used for the dashboard module
erp-ui-work-order-mgmntReact front end used for work order operations

Basic project structures

We can see some similarities between the two stacks, most noticably the concept of packages in the Java implementation. In both cases, there is the concept of tiers (controller, service, and persistence). Source code is organized into folders accordingly. This is a default practice for ‘smaller‘ projects, whereas as a codebase grows you might find yourself beggining to break controllers/services/entities into functional named subfolders.

An alternate approach is to organize functions into more of a structure where code is placed into feature specific folders, whereas for example, given an ‘Customer‘ entity , a customer folder would be created, and all controller, router/controller, and associated logic would be packaged under the same folder.

This is a highly opinionated topic, with pros and cons for each approach. I would not even attempt to make a strong opinion here. It really boils down to your own opinion, and needs for your specific team and project. I am defaulting to this one approach. This may not be the best fit for every scenario.

Code Generation

I love working on new projects (most of us probably do), however this involves a lot of boilerplate work, which is necessary however redundant. I have typically use code generation techniques for various projects to streamline these types of tasks, and will be using one on this project.

A very common operation is where an entity is created, an API is required to support operations against it, logic to hydrate/persist the entity, and perhaps code related to a service tier. That gets old pretty quick so automating as much as possible adds value.

Build Environments

I believe it is especially important to establish a build environment as quickly as possible. It is pretty common place to establish a build pipeline, but not necessarily a safe assumption, I have seen cases where deployments were performed directly from a developers laptop.

Support for testing

I am a firm believer in testing from day one. Usually one the first tasks I attempt is to execute a small test case to support functionality as a flight check. This is also a required task as we are planning on establishing unit level tests at deployment build time. For Java we will be using JUnit, and for React Jest.

Build pipeline

The associated source code is publicly available on GitHub with the following links. All projects may be located at the following location.