System architecture overview

System architecture has always been one of the most challenging problems for Software Engineers. Design patterns are numerous, but choosing one to apply in our project is really a problematic move, one of the game-changing points. Hence, we must balance our choices while ensuring that the system:

  • Works correctly
  • Easy to maintain and repair
  • Easy to upgrade
  • Easy to test
  • Keep high performance

The design of OMS has been carefully researched, guaranteed to avoid under architect and over architect. We also applied additional Clean Architecture techniques to make the source code more understandable and easy to use. At the same time, the implementation must be polished, allowing unit testing easily to follow TDD and BDD closely to make source code more efficient. Let's analyze some famous Architectural Software Design Pattern to find a suitable option.

Model View Controller (MVC)

When it comes to building a web application, we cannot ignore the MVC pattern. This is the most common model for building an effective application. As a simple, easily accessible model, the MVC model proved to be extremely useful in solving common problems. The power of MVC comes from the effective interaction of three main components: Model (data management), View (interface renderer) and Controller (main logic block of the application).

But in OMS, the big picture that we describe in the previous section really raised a question. Can a simple 3 layer only design help us organize a stable application or not. Gathering all the business logic into the controller makes the layer filled with extremely confusing business rules. The model must perform DB access, attribute consolidation, and execution of business requirements. If we merge the business logic into the Model layer, using SQL to install the central part, we may put too many logic into complex queries of this layer. The preferred method is the use of ORMs. Using ORM is effective but simple:

  • This causes the data and business layer to merge, making it harder to make efficient unit test
  • Accessing and operating on the same model may become difficult because the two parts' data requirements may be different.
  • CRUD requires a locking coordinator when reading and writing data occurs continuously, which is a very common use-case when we design OMS system.

In a fast-moving environment and much complex business logic such as eCommerce, applying MVC can bring some brand benefits such as fast implementation, easy to develop in early-stage, easy to get used to ... but really is a problem when the system is booming in terms of business.

Domain Driven Design (DDD)

The DDD model was introduced by Eric Evans in a 2003 book of the same name. It comes with many principles for developing a complicated application. This approach focused not only on clear the gap between the business team and the development team for better communication, but also guided us to structure the application into multiple layers with many modules. Compared to it, MVC exclusively focuses on business dispersion and processing.

  • User Interface Layer: visually represents information to the user and compiles the user requests into commands, which will be handled downstairs
  • Application Layer: coordinate the application's commands to where they can be processed
  • Domain Layer: At the heart of the application, it maintains the Business Object's states and processes them before transferring them to the Infrastructure bottom layer for further storage or processing.

This model has the strength of being able to bridge the Developer and B. A quickly as the business layer has been carefully separated independently from the Infrastructure and User Interface layers. We can easily modify and add code that is easy to understand / easy to check against business logic without having worry depending on framework or library syntax because they are isolated outside.

DDD's methodology classifies internal entities for programmers for easy designation such as Entities, Value Objects, Domain Objects, Domain Logic, etc. But inside that also contains the same ideas as Clean Architecture is to help the developer understand the clear principles of designing to build layers that are stable and durable.

The DDD model is worthy of our attention, but using a single model class to build the application will make it difficult for us to continue to associate the different requirements of data retrieval and access. Models bulge and tightening into ORM models affect performance, making it difficult to change the logic on data.

Let's study how to improve DDD's Domain Layer with the CQRS pattern.

Command Query Responsibility Segregation (CQRS)

CQRS (Command Query Responsibility Segregation) model was introduced by Bertrand Meyer. The summary of CQRS is dividing the system into two main logical arrays: Command and Query.

  • Command side focuses on addressing business needs that change data such as operations on user orders like editing orders and delete orders
  • Query side focuses on transforming data into the format that the user needs.

CQRS may not need DDD, but it will bring the expansion of the DDD Domain Layer. And DDD also helps to extend the concept to separate the business of CQRS more clearly than ever through the Aggregate root.

Overcoming the limitation of containing too much business logic, CQRS offers many advantages:

  • The system is clearly divided logic, easy to test on each feature
  • Allow individual optimization without affecting data consistency
  • Many people can participate in the development of user features - independent commands at the same time
  • Communication with the Business team is further improved, able to make independent features, less dependent on each other. Team business can use these concepts to build more visually.
  • Modeling of data-changing operations by command increases atomic change capability, helping us to capture data changes rather than using CRUD, an internal audit logging has been established.

Command design can also come with abstracting a command bus class to distribute the command for different parts of the execution, which has advantages.

  • It is possible to increase the power of the system by switching back and forth between synchronous and asynchronous processing.
  • Scalability increases for the future

Event Sourcing (ES)

CQRS has solved the complicated logic problem; now, there is ES ?. Is there any more magic in this phrase?
Event sourcing, presented by Eric Evans (also, the father of DDD), comes with a main simple idea that our system, instead of being dominated by countless entities, will be constituted by a system of events.

What is Event?

Events (Transaction, Delta) are changes that occur in data of an entity recorded by the system.
In OMS, Order from the Event Sourcing view is a collection of records of events on the order:

     1. An order is created
     2. The are confirmed
     3. WMS confirms exporting goods
     4. Logistic successful delivery

Modeling the system into a series of events helps us isolate the change of the main object, in order to efficiently manage and divide the work, and adapt to change. The state of the order which is adjusted according to CRUD can be entirely re-expressed by events, even more, modeling order by events has many other advantages such as:

  • Internal audit logging allows trace of all user behavior on orders, providing a vast amount of data for business development.
  • Can recalculate the status of orders at various times, quickly check for errors.
  • Say goodbye to the fear of having to handle large volumes of processing and retrieving orders to lock the data. Under the event sourcing, all the data is just added, not deleted, not modified.
  • Accurately modeling real-life domains, as a bridge between Dev and B. A
  • ES is a great concept to apply to distributed systems when most of the distributed consensus algorithms rely primarily on data fragmentation.

Conclusion

We have gradually formed an overview of the complete system architecture of an OMS through presented patterns.

  • MVC gives us strength from simplicity but is limited because the layer logic is not clearly divided and challenging to expand
  • DDD provides us with a method for separating layer logic more clearly, facilitating connecting with the Business team easily, systematically, and efficiently transforming into code.
  • CQRS divides and optimizes the reading and writing logic of Domain Objects in DDD; thus, it helps to improve clarity and increases performance when allowing for independent multi-part optimization.
  • CQRS / ES brings new power when instead of using a big Domain Object with complicated ORM design, we will model our Domain Object by events. This brings many advantages to the simplicity and scalability of the business object.

However, there are still many weaknesses that CQRS / ES will address in this article.

  • It is a complex model and difficult to learn
  • There is no standard design, so you have to research it yourself for your project

In the next section, we will go through the process of making all the mentioned thesis into work. Also, problems are encountered during the installation that will be addressed and solved then.