JavaScript Full Stack real world business system step-by-step guide. Part 2: Main design decisions

In previous article has been described business case and product’s functional structure that allow us to design:

• domain model that will be descibed as set of objects
• TypeORM entities scheme based on interfaces of domain model
• relational database schema that wil be generated using TypeORM migrations
• user interface mockups
• environment and project structure for nx workspace

This aricle describes main design decisions to prepare and plan the development process

Database design decisions

Basic functional structure helps us to see clearly domain area objects of our system. Here they are:

1. Role. To manage data of user’s roles
2. User. To manage data of system’s users
3. Truck Driver. To manage data of truck drivers
4. Truck. To manage  data of company’s trucks
5. Customer. To manage data of company’s customers
6. Order. To manage data of customer’s orders
7. Offer. To manage  data of offers for customer’s orders
8. Note. To  manage data of notes for customer’s orders
9. Chat Messages To manage messages of customer’s orders
10. Action. To manage data of process actor’s actions (Actions it’s something like to do tasks to complete step of process)

Also we need some additional auxiliary objects such as:

1. TransportTypes. To manage data of transport types and subtypes
2. Truck Statuses. To manage data of availability statuses for example free, ordered, under maintenance
3. Order statuses. To manage data of order statuses to tracking state of order processing
4. Action Statuses. To manage data of action statuses
5. UsersStatuses. To manage data of statuses users
6. Entities. To manage data of enities to sort actions

And тo design and develop relatiton database for our system also we need some objects to join:

1. Drivers and trucks
2. Managers and customers

And our database schema shown in the picture below:

Probably some changes will be made to this scheme during development process.

User Interface design decisions

We will  design clean and simple user interface based on Angular Material library with using default indigo palettes. Our system homepage will look like this:

In the header we will use toolbar menu with icons and menu forms like picture below

Side navigation menu will be unique to  each role except for the Admin and Director roles but their functionality will differ at a deeper level of usage.

Menu for the Admin and Director roles:

• Users
• Drivers
• Trucks
• Managers
• Customers
• Orders
• Offers
• Notifications
• Actions

Menu for the Customer role:

• Orders
• Offers
• Notifications
• Actions

Menu for Manager role:

• Customers
• Orders
• Offers
• Drivers
• Trucks
• Notifications
• Actions

Menu for Driver role:

• Notifications
• Actions

Each functional feature in menu will have standard view. For example Trucks

Context menu will be looks like this:

For example Admin role have permission to work with delete items for each feature that is why it will have Deleted items button

And list of deleted items will have another context menu like this

The standard forms for operations with entities data such as create or update will be look like on picture below or in a dialog window style

But our system also will have a complex forms for eample for Orders feature. Design of these forms will be discussed further as the project progresses.

Environment and project structure design decisions

We will use NestJS for backend, and Angular for frontend inside NX workspase to build monorepository solution, because it has some advantages compared to the separate backend and frontend development approach. The main advanages is ability to develop domain object oriented model to use it both in backend and fronted.

Overall, Awesome Trucks Company System will be developed in NX style with the exception of two moments:

• Backend app will be developed in one library because we develop solution using realtional data model based on TypeORM where all entities are joined based on defined domain model. That is why I don’t see the point in implementing functionality with linked entities as set of separated libraries.
• I don’t develop separate app for each user role as it is commonly used in NX project. Instead, there will be a single frontend application where, depending on the user’s role, the application will offer ith own main menu and functionality.

Thus, the basic nx workspace structure of our project look like the image below

Summary and conclusions

This article briefly shows some design decisions regarding the database, user interface and project workspace structure to understand common vision of the project.  This decisions will be further developed during the system’s ongoing development and described in subsequent articles.  In the next article project will be divided into milestones and their content will be defined to facilitate tracking its progress.

Full list of articles in the series 

1. Introduction: Business Case and main requirements
2. Main design decisions
3. Project planning decisions
4.1. Develop Full Stack Boilerplate: workspace, environment and database preparation
4.2 Develop Full Stack Boilerplate: Create backend authentication with JWT, PassportJS and Cookies