Challenges of developing an enterprise web solution

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.