Architecting an enterprise application

The following architectural diagram depicts what we are building. We need to bear in mind all of the design principles, patterns, and requirements that we have seen in this chapter when we are architecting and developing the application. The following diagram shows the proposed architecture for our e-commerce enterprise application:

Figure 1.15 – The e-commerce application's three-tier architecture

Separation of concerns/SRP has been taken care of at each tier. The presentation tier, containing the UI, is separated from the services tier containing the business logic. This is again separated from the data access tier containing the data store.

The high-level components are unaware of the low-level components consuming them. The data access tier is unaware of the services consuming it, and the services are unaware of the UX tier consuming them.

Each service is separated based on the business logic and functionality it is supposed to perform.

Encapsulation has been taken care of at the architecture level and should be taken care of during development, too. Each component in the architecture will be interacting with other components through well-defined interfaces and contracts. We should be able to replace any component in the diagram without having to worry about its internal implementation and whether it adheres to the contracts.

The loosely coupled architecture here also helps with faster development and faster deployment to the market for customers. Multiple teams can work, in parallel, on each of their components independently. They share the contracts and timelines for integration testing at the start, and once the internal implementation and unit tests are done, they can start with integration testing.

Refer to the following diagram:

Figure 1.16 – The eCommerce application's three-tier architecture with highlighted chapters

From the preceding diagram, we can identify the chapters in which different parts of the e-commerce application that we will build will be covered. They can be explained as follows:

• Creating an ASP.NET web application (our e-commerce portal) will be covered in Chapter 11, Creating an ASP.NET Core 6 Web Application.
• Authentication will be covered in Chapter 12, Understanding Authentication.
• The order processing service and the invoice processing service are the two core services for generating orders and invoicing. They will be the heart of the e-commerce application as they are the ones that are responsible for the revenue. Creating an ASP.NET Core web API will be covered in Chapter 10, Creating an ASP.NET Core 6 Web API, and cross-cutting concerns will be covered in Chapter 5, Dependency Injection in .NET 6, Chapter 6, Configuration in .NET 6, and Chapter 7, Logging in .NET 6, respectively. The DRY principle will be taken care of by reusing core components and cross-cutting concerns instead of repeating implementations.
• Caching will be covered as part of the product pricing service in Chapter 8, All You Need to Know about Caching. Caching will help us to improve the performance and scalability of our system, with temporary copies of frequently accessed data being available in memory.
• Data storage, access, and the number of providers will be covered as part of the data access layer in Chapter 9, Working with Data in .NET 6. The kind of architecture that we have adopted, where data and access to it are separate from the rest of the application, gives us better maintenance. Azure Cosmos DB is our choice to scale throughput and storage elastically and independently across any number of Azure regions worldwide. Additionally, it is secure by default and enterprise-ready.

This concludes our discussion on architecting our enterprise application. Next, we will look at the solution structure for our enterprise application.