Building software systems has always been complicated. Especially in these modern times, there are many challenges while creating even a basic business solution. You often find yourself implementing standard non-business requirements and digging into infrastructure problems rather than implementing your business code, which is the actual valuable part of the system you are trying to build.

ABP Framework helps you focus on the code that adds value to the stakeholders by offering a robust software architecture, automating the repetitive details, and providing the necessary infrastructure to help build modern web solutions. It provides an end-to-end, consistent development experience and improves your productivity. ABP gets you and your team up to speed with all the modern software development best practices pre-applied.

This book is the ultimate guide to developing web applications and systems using ABP Framework by following modern software development approaches and best practices.

This first chapter introduces the challenges of building a well-architected enterprise solution and explains how ABP Framework addresses these challenges. I will also explain the purpose and the structure of this book.

In this chapter, we will cover the following topics:

• Challenges of developing an enterprise web solution
• Understanding what ABP Framework offers

Before digging into ABP Framework, I want to present the challenges of developing a modern enterprise web solution to understand why we need an application framework like ABP Framework. Let's begin with the big picture: architecture.

Setting up the architecture

Before you start to write your code, you need to create a foundation for your solution. This is one of the most challenging phases of building a software system. You have a lot of options and need to make some fundamental decisions. Any decision you make at this stage will likely affect your application for the rest of its lifetime.

There are some common, well-known, system-level architectural patterns, such as monolithic architecture, modular architecture, and microservice architecture. Applying one of these architectures determines how you develop, deploy, and scale your solution and should be decided based on your requirements.

In addition to these system-level patterns, software development models such as Command and Query Responsibility Segregation (CQRS), Domain-Driven Design (DDD), Layered Architecture, and Clean Architecture determine how your code base is shaped.

Once you decide on your architecture, you should create the fundamental solution structure to start development with that architecture. In this phase, you also need to decide which language, framework, tools, and libraries you will use.

All these decisions need significant experience, so they are ideally done by experienced software architects and developers. However, not all the team members will have the same experience and knowledge level. You need to train them and determine the correct coding standards.

After setting up your architecture and preparing the fundamental solution, your team can start the development process. The next section discusses the common aspects that are repeated by every software solution and how you can avoid repeating them in your development.

Don't repeat yourself!

Don't Repeat Yourself (DRY) is a key principle for software development. Computers automate the repetitive tasks of the real world to make people's lives easier. So, why do we repeat ourselves while building software solutions?

Authentication is a very common concern of every software solution – single sign-on, Active Directory integration, token-based authentication, social logins, two-factor authentication, forgot/reset password, email activation, and more. Are most of these requirements are familiar to you? You are not alone! Almost all software projects have more or less similar requirements for authentication. Instead of building all these from scratch, using an existing solution, such as a library or a cloud service, is better. Such pre-built solutions are mature and battle-tested, which is important for security.

Some non-functional requirements, such as exception handling, validation, authorization, caching, audit logging, and database transaction management, are other sources of code repetition. These concerns are called cross-cutting concerns and should be handled in every web request. In a well-architected software solution, these concerns should be handled automatically by conventions in a central place in your code base, or you should have services to make them easier to implement.

When you integrate to third-party systems, such as RabbitMQ and Redis, you typically want to create abstractions and wrappers around the code that interact with these systems. In this way, your business logic is isolated from these infrastructure components. Also, you don't repeat the same connection, retry, exception handling, and logging logic everywhere in your solution.

Having a pre-built infrastructure to automate this repetitive work saves your development time so that you can focus on your business logic. The next section discusses another topic that takes up our time in every business application – the user interface.

Building a UI base

One of the fundamental aspects of an application is its user interface (UI). An application with an unfashionable and unusable UI would not be as attractive at first glance, even if it has outstanding business value under the hood.

While UI features and requirements vary for every application, some fundamental structures are common. Most applications need basic elements, such as alerts, buttons, cards, form elements, tabs, and data tables. You can use HTML/CSS frameworks such as Bootstrap, Bulma, and Ant Design instead of creating a design system for every application.

Almost every web application has a responsive layout with the main menu, toolbar, header, and footer with custom colors and branding. You will need to determine all these and implement a base UI kit for your application's pages and components. In this way, UI developers can create a consistent UI without dealing with the common structures.

Up to here, I've introduced some common infrastructure requirements, mostly independent from any business application. The next section discusses common business requirements for most enterprise systems.

Implementing common business requirements

While every application and system is unique and their value comes from that uniqueness, every enterprise system has some fundamental supporting requirements.

A permission-based authorization system is one of these fundamental requirements. It is used to control the privileges of users and clients of the application. If you want to implement this yourself, you should create an end-to-end solution with database tables, authorization logic, permission caches, APIs, and UI pages to assign these permissions to your users and check them when needed. However, such a system is pretty generic and can be developed as a shared identity management functionality (a reusable module) and used by multiple applications.

Like identity management, many systems need functionalities such as audit log reporting, tenant and subscription management (for SaaS applications), language management, file uploading and sharing, multi-language management, and time zone management. In addition to the pre-built application functionalities (modules), there may be low-level requirements, such as implementing the soft-delete pattern and storing Binary Large Object (BLOB) data in your applications.

All these common requirements can be built from scratch, which can be the only solution for some enterprise systems. However, if these functionalities are not the main value that's provided by your application, you can consider using pre-built modules and libraries where they are available and customize them based on your requirements.

In the next section, you will learn how ABP Framework helps us with the common infrastructure and base requirements that were discussed in this section.

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.

Domain-driven design

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.

Modularity

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.

Modularity has two main challenges that are simplified with ABP Framework:

• 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

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.

SaaS/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.

The community

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.

In this chapter, we introduced the problems of building a business solution and explained how ABP provides solutions to these common problems. ABP also increases developer productivity by providing a pre-built architectural solution and the necessary infrastructure to implement that architecture.

By the end of this book, you will be comfortable with ABP Framework and will have learned a lot of best practices and techniques regarding enterprise software development.

In the next chapter, you will learn how to create a new solution using ABP's command-line interface (CLI) tool and run it in your development environment.