Architecting an enterprise application

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

Figure 1.13 – Our e-commerce application's three-tier architecture diagram

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, which 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 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 as well. 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 worrying about its internal implementation if it adheres to the contracts.

The loosely coupled architecture here also helps in faster development and faster deployment to 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 figure:

Figure 1.14 – Our e-commerce application components, broken down by chapter

From the figure, we identify the chapters in which different parts of the e-commerce application that we will build will be covered, which are explained as follows:

• Creating an ASP.NET web application (our e-commerce portal) will be covered as part of Chapter 11, Creating an ASP.NET Core 5 Web Application.
• Authentication will be covered as part of 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 as part of Chapter 10, Creating an ASP.NET Core 5 Web API, and cross-cutting concerns will be covered as part of Chapter 5, Dependency Injection in .NET, Chapter 6, Configuration in .NET Core, and Chapter 7, Logging in .NET 5, 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, Understanding Caching. Caching will help to improve the performance and scalability of our system, with temporary copies of frequently accessed data being available in memory.
• Data storage, access, and providers will be covered as part of the data access layer in Chapter 9, Working with Data in .NET 5. The kind of architecture that we have adopted, where data and access to it is 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. It is also 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.