Enterprise Architect - Which pattern should I use?

Overview

In this article, we will discuss about the number of patterns which can be used for your application.

There are many types of pattern for the simple to complex application as below:

1. Multiple-Tiers
2. Reporting database
3. CQRS
4. CQRS-DDD-ES
5. Microservice
6. Microservice-CQRS-DDD-ES

We will go through one by one briefly

Multiple-Tiers

In this pattern, we simply divide the application into 2 or multiple separated layers, each has its own purpose/ responsibility.

Commonly, we usually have those layers for simple web-api application:

• Controller: defines access point that can be called from remote client
• Service: handles business rules, validate information
• Repository: performs repository I/O operation

An overview diagram about this pattern as below:

For example, With simple user creation, we can have this code in each layer as below:

Controller (UsersController.cs):

[RoutePrefix("api/users")]
public class UsersController{
	[HttpPost]
	[Route("")]
	public Guid CreateUser(CreateUserRequest request){
		UserService service = new UserService();
		return service.Create(request);
	}
}

 And Service layer (UserService class):

public class UserService{
	public Guid CreateUser(CreateUserRequest request){
		this.ValidateCreateUserRequest();
		UserRepository repository = new UserRepository();
		return repository.Add(new User(request.FirstName, request.LastName, request.Email));
	}
}

And Repository layer (UserRepository class):

public class UserRepository{
	public Guid Add(User user){
		DbContext dbContext = new DbContext();
		dbContext.Users.Add(user);
		dbContext.SaveChanges();
		return user.Id;
	}
}

 This is pseudo code, please do not try to run it.

We can see that, service layer acts as the heart of you system. all the business and validation rules were there.

Scale

In this pattern, all data goes into single database. this can increase the size of database to hundred of GB which is not good from the view of performance and maintenance.

There are some plans for scaling your database:

• Partition: please search on internet for more information.
• Split your table: Split big table into smaller tables using some rules, such as:  
  • Order with ID between 0 and 1.000.000 will goes into Order_1 table
  • Order with ID between 1.000.001 and 2.000.000 will goes into Order_2 table

So, we can base on ID of order to know which table should we get the order from.

• Split your database: We will break the database of the application into smaller, isolated databases by grouping related data together. Such as:
  • All data related to Order should be located in Order database
  • All data related to Purchase should be located in Purchase database ...

Of course, Getting/ updating data that was spanned through multiple databases will be more complex. In this case, we need to use distributed transaction or event driven pattern for solving this issue.

Belong to specified type of application, we may select different plan to scale your database.

Below is the diagram of multi layers for multiple database:

All the business was implemented in service layer, so in the future, we can add new feature into for our application with out rewrite what has been done, such as: support web and mobile application also. What we need to do in this case is "Build the web/ mobile UI" and "attach" into current system. It will work well.

When should I use?

This is the right pattern for the case we have the simple business, such as CRUD user or small stand alone feature, ...

For more information, how did we use this in TinyERP, Please have a look at this link (click me). Check the api part please.

Reporting database

We usually applied this pattern for management application, such as: Timesheet, HRM, SCM, ....

For those types of application, we need to see many reports which collect data form many sources, tables...

We usually join between tables, perform many calculations when retrieving this data. This raises performance issues. As joining between 2 table with 10.000.000 records usually takes around 5 minutes or more is normal.

So in this case, if the system prepareed reporting data for us automatically and store it some where( in other table, other database, or files ...).

Then, we just come and get the expected data as we need and do not need to calculate. This also increase performance of our application in total.

Photo below, describing an overview about how it works:

In this pattern, we usually have separated write side and read side.

• Write side: for all actions that can change the state of data in system, this usually implements all logic of the application in this side and store data into master repository. Then there will be scheduled tasks or subscribed events which sync changes to repository for read side.
• Read side: this usually a thin layer, which goes to appropriated repository and get expected data was stored in expected location/ repository in expected format.

Look at scenario below and see how will it work:

User wants to create new order contains information of customer, order-line (by what, price, ...). Then manager would like to see sale report(including total number of orders, total income for current day).

The photo below describe step by step:

1. Client app will send CreateOrderRequest to OrderController for creating new order. CreateOrderRequest contains all necessary information to create new order.
2. OrderController sends CreateOrderRequest to OrderService, this is where the CreateOrderRequest was validated, if all business rules were passed( customer balance, stock in inventory, ...) new order will be created.
3. New order will be saved into master repository. Customer balance, stock in inventory were also updated.
4. There will be scheduled tasks/ subscribed events for updating these changes to read database.
5. Manager requests to see the sale report.
6. This request was passed to another service and continue forwarded to repository
7. Repository just reads necessary data from read database.

We can see that, at the time of retrieving data for sale report, the application just goes to read database and get expected data. There is not extra calculation. So the operation will be executed faster, thus improve performance of the application in total.

Thank you for reading, CodeProject

Note: Please like and share to your friends if you think this is usefull article, I really appreciate