ABP Framework offers an opinionated architecture to help you build enterprise software solutions with best practices on top of the .NET and ASP.NET Core platforms. It provides the fundamental infrastructure, production-ready modules, themes, tooling, guides, and documentation to implement that architecture properly and automate the details and repetitive work as much as possible.
In the next few sub-sections, I will explain how ABP does all these, starting with the architecture.
The ABP architecture
I mentioned that ABP offers an opinionated architecture. In other words, it is an opinionated framework. So, I should first explain what an unopinionated framework is and what an opinionated framework is.
As I stated in the Setting up the architecture section, preparing a foundation for a software solution requires a lot of decisions; you should decide on the system architecture, development model, techniques, patterns, tools, and libraries to use in your solution.
Unopinionated frameworks, such as ASP.NET Core, don't say much about these decisions and mostly leave it up to you. For example, you can create a layered solution by separating your UI layer from the data access layer, or you can create a single-layered solution by directly accessing the database from your UI pages/views. You can use any library, so long as it is compatible with ASP.NET Core, and you can apply any architectural pattern. Being unopinionated makes ASP.NET Core flexible and usable in different scenarios. However, it assigns the responsibility to you to make all these decisions, set up the right architecture, and prepare your infrastructure to implement that architecture.
I don't mean ASP.NET Core has no opinion at all. It assumes you are building a web application or API based on the HTTP specification. It clearly defines how your UI and API layers should be developed. It also offers some low-level infrastructure components such as dependency injection, caching, and logging (in fact, these components are usable in any .NET application and not specific to ASP.NET Core, but they are mainly developed alongside ASP.NET Core). However, it doesn't say much about how your business code is shaped and which architectural patterns you will use.
ABP Framework, on the other hand, is an opinionated framework. It believes that certain ways of approaching software development are inherently better and thus guide developers down those paths. It has opinions about the architecture, patterns, tools, and libraries you will use in your solution. Though ABP Framework is flexible enough to use different tools and libraries, and change your architectural decisions, you get the best value when you follow its opinions. But don't worry; it provides good, industry-accepted solutions to common architectures to help you build maintainable software solutions with best practices. The decisions it takes will save your time, increase your productivity, and make you focus on your business code rather than infrastructural problems.
In the next few sections, I will introduce the four fundamental architectures ABP stands on.
ABP's main goal is to provide a model to build maintainable solutions with clean code principles. ABP offers a layered architecture based on DDD patterns and practices. It provides a layered startup template (see The startup templates section), the necessary infrastructure, and guidance for applying that architecture properly.
Since ABP is a software framework, it focuses on the technical implementation of DDD. Part 3, Implementing Domain-Driven Design, of this book explains the best practices of building a DDD-based solution using ABP Framework.
In software development, modularity is a technique that's used to split a system into isolated parts, called modules. The ultimate goal is to reduce complexity, increase reusability, and enable different teams to work on different sets of features in parallel without affecting each other.
- The first challenge is to isolate modules. ASP.NET Core has some features (such as Razor component libraries) to support modular applications. Still, it is very limited because it is an unopinionated framework and has opinions only for the UI and API parts. On the other hand, ABP Framework provides a consistent model and infrastructure to build fully isolated, reusable application modules with its database, domain, application, and UI layers.
- The second challenge of modularity is dealing with how these isolated modules communicate and become a single, unified application at runtime. ABP offers concrete models for common requirements of a modular system, such as sharing a database among modules, communicating between the modules via events or API calls, and installing a module in an application.
ABP provides many pre-built open source application modules that can be used in any application. Some examples include the Identity module, which provides user, role, and Permission Management, and the Account module, which provides login and register pages for your application. Reusing and customizing these modules saves your time. In addition, ABP provides a module startup template to help you build reusable application modules. An example of this can be found in Chapter 15, Working with Modularity.
Modularity is great for managing the complexity of a large monolithic system. However, ABP helps you create microservice solutions too.
Microservices and distributed architecture is the accepted approach to building scalable software systems. It allows different teams to work on different services and independently version, deploy, and scale their services.
However, building a microservice system has some important challenges in terms of development, deployment, inter-microservice communication, data consistency, monitoring, and more.
Microservice architecture is not a problem that a single software framework can solve. A microservice system is a solution that brings many different disciplines, approaches, technologies, and tools together to solve unique problems. Every microservice system has its requirements and restrictions. Each team has a level of expertise, knowledge, and skills.
ABP Framework was designed to be microservice compatible from the beginning. It provides a distributed event bus for asynchronous communication between microservices with transaction support (as explained in the Publishing domain events section of Chapter 10, DDD – The Domain Layer). It also provides C# client-side proxies to easily consume the REST APIs of remote services (as explained in the Consuming HTTP APIs section of Chapter 14, Building HTTP APIs and Real-Time Services).
All of the pre-built ABP application modules are designed so that you can convert them into microservices. ABP also provides a detailed guide (https://docs.abp.io/en/abp/latest/Best-Practices/Index) to explain how you can create such microservice-compatible modules. In this way, you can start with a modular monolith, and then convert it into a microservice solution later.
The core ABP team has prepared an open source microservice reference solution built with ABP Framework. It demonstrates how you can create a solution with API Gateways, inter-microservice communication, distributed events, distributed caches, multiple database providers, and multiple UI applications with single sign-on. It also includes the Kubernetes and Helm configurations to run the solution on containers. See https://github.com/abpframework/eShopOnAbp to learn all the details about that solution.
The next section introduces the last fundamental architecture that ABP Framework provides out of the box – multi-tenancy.
Software-as-a-Service (SaaS) is a trending approach to building and selling software products. Multi-tenancy is a widely used architectural pattern for building SaaS systems. The following are the typical features of a multi-tenant system:
- Shares the hardware and software resources between tenants.
- Every tenant has users, roles, and permissions.
- Isolates database, cache, and other resources between tenants.
- Can enable/disable application features per tenant.
- Can customize application configurations per tenant.
ABP Framework covers all these requirements and more. It helps you build a multi-tenant system while most of your code base is unaware of multi-tenancy.
Chapter 16, Implementing Multi-Tenancy, explains multi-tenancy and multi-tenant application development with ABP Framework.
So far, I've introduced the fundamental architectural patterns that ABP provides as pre-built solutions. However, ABP also provides startup templates to help you get started with a new solution easily.
The startup templates
When you create a new solution using ASP.NET Core's standard startup templates, you get a single-project solution with minimal dependencies and no layers, which is not so production-ready. You usually spend a considerable amount of time setting up the solution structure to implement your software architecture properly, as well as to install and configure the fundamental tools and libraries.
ABP Framework provides a well-architected, layered, pre-configured, and production-ready startup solution template. The following screenshot shows the initial UI when you directly run the startup template that's created with ABP Framework:
Figure 1.1 – ABP application startup template
Let's talk about this startup template in more detail:
- The solution is layered. It is clear and tells you how to organize your code base.
- Some pre-built modules are already installed, such as the Account and Identity modules. You have log in, register, user and role management, and some other standard functionalities already implemented.
- Unit test and integration test projects are pre-configured and ready to write your first test code.
- It contains some utility applications to manage your database migrations and consume and test your HTTP APIs.
ABP's application startup template comes with multiple options for the UI Framework and the Database Provider. You can start with Angular, Blazor, or MVC (Razor Pages) options as the UI framework, and use Entity Framework Core (with any database management system) or MongoDB as the database provider. You will learn how to create a new solution and run it in Chapter 2, Getting Started with ABP Framework.
In the next section, I will introduce some of ABP's infrastructure components.
The ABP infrastructure
ABP is based on familiar tools and libraries you already know about. While it is a full-stack application framework, it doesn't introduce a new Object-Relational Mapper (ORM) and instead uses Entity Framework Core. Similarly, it uses Serilog, AutoMapper, IdentityServer, and Bootstrap instead of creating similar functionalities itself. It provides a solution that integrates these tools, fills the gaps, and implements common business application requirements.
ABP Framework simplifies exception handling, validation, authorization, caching, audit logging, and database transaction management by automating them by conventions and allowing you to fine-control when you need to. So, you don't repeat yourself for these cross-cutting and common concerns.
ABP is well integrated with IdentityServer for cookie and token-based authentication, as well as single-sign-on. It also provides a detailed, permission-based authorization system to help you control the privileges of the users and clients of the application.
Besides the basics, background jobs, BLOB storage, text templating, audit logging, and localization components provide built-in solutions for common business requirements.
On the UI part, ABP provides a complete UI theming system to help you develop theme-unaware and modular applications and easily install a theme for an application. It also provides tons of features and helpers on the UI side to eliminate repetitive code and increase productivity.
The next section will talk about the community, which is important for an open source project.
When you set up your solution architecture in your company, no one knows your structure except the developers working on it. However, ABP has a large and active community. They are using the same architecture and infrastructure, applying similar best practices, and developing their application similarly. This has a great advantage when you are stuck with an infrastructure problem or want to get an idea or a suggestion for implementing a business problem. It is also easier to understand someone's code in another solution since ABP developers are applying the same or similar patterns.
ABP Framework has been around and growing since 2016. At the end of 2021, it has 7,000+ stars, 220+ contributors, 22,000+ commits, 5,700 closed issues on GitHub, and more than 4,000,000 downloads on NuGet with more than 110+ major and minor releases. I mean, it is a mature, accepted, and trusted open source project.
The core ABP team and the contributors from the community are constantly writing articles, preparing video tutorials, and sharing on the ABP Community website: https://community.abp.io. The following screenshot has been taken from the ABP Community website:
Figure 1.2 – The ABP Community website
Check out the ABP Community website to see what others are doing with ABP Framework and closely follow ABP Framework's development.