Clean Architecture: Key Concepts

Introduction

Every application should have some structure, some architecture. There are key components to any application, no matter the size. Here we cover what these components are. These components or code containers, allow us to organize our code. The application then becomes easy to maintain and flexible to change.

What is Architecture

It is believed that the architecture or design intent of the system should be reflected in the application structure, not in accompanying documentation.

A good starting point for this is folder structure.

Even on a small scale we need containers of code. A way to organize code so that we know where bits of code should go to make it easy for us to maintain as a team. The architecture itself is a language, a language of system structure.

What are Business Rules, Business/Domain Logic?

The concept of business rules has nothing to do with technology. The development of business rules is developed from the best possible approach to business operations. Business rules, in their simplest definition, are directives that define business activities.

Business logic is the implementation of business rules or algorithms that handle the exchange of information between a database and user interface. Business logic is essentially part of a computer program that contains the information (in the form of business rules) that defines how the system operates. Business logic can be seen in the workflows or use cases, such as in sequences or steps that specify in detail the proper flow of information or data, and therefore decision-making.

Business logic is also known as “domain logic”.

What are Use Cases?

A use case is a definition of a specific business objective that the system needs to accomplish. A use-case will define this process by describing the various external actors (or entities) of the system, together with the specific interactions they have with the system in the accomplishment of the business objective.

There are types of Use Cases

Business Use Case - These are technology-agnostic use cases that are high-level business processes (e.g. “create invoice”) and the various external entities that take part in the process (e.g. “product”, “customer”, etc). The business use case will define the sequence of activities that the business needs to perform to give task. Each of these business use cases should be kept in its own clearly named file.

System Use Case - Also known as an “Implementation Use Case”, these use cases are written at a lower level of detail than the business use case and refer to specific processes that will be carried out by different parts of the system. For example a system use case might be “return outstanding invoices” and would describe the interactions within the system in carrying out an end-to-end process. These types of system use cases will be kept in system repository files

What is a Data Source?

A data source is the location where data originates from. Concretely, a data source may be a database, a flat file, live measurements from physical devices, scraped web data, or any of the myriad static and streaming data services which abound across the internet. A data source is the physical or digital location where data under question is held in the form of a data table, data object, or other storage format.

A data source is

1. the physical or digital location where data under question is stored as a data table (or other format),
2. the degree of originality of a data table,
3. a brand name data provider
4. the data used via a self-service data tool such as Excel, Tableau, or Power BI,
5. the computer storage type, e.g. File Data Source or Machine Data Source,
6. a technical database such as Amazon AWS or Microsoft Azure
7. a legacy data source with a proper name within an organization,
8. a data type such as stock, accounting, or economic indicator.

Here’s an example of a data source in action. Imagine a fashion brand selling products online. To display whether an item is out of stock, the website gets information from an inventory database. In this case, the inventory tables are a data source, accessed by the web application which serves the website to customers.

Ultimately, data sources are intended to help users and applications connect to and move data to where it needs to be. They gather relevant technical information in one place and hide it, so data consumers can focus on processing, visualizing and identify how to best utilize their data.

The purpose here is to package connection information in a more easily understood and user-friendly format. This makes data sources critical for more easily integrating disparate systems, as they save stakeholders from the need to deal with and troubleshoot complex and low-level connection information.

Once data has arrived at its final destination, preferably a centralized repository such as a cloud data warehouse, differences in formatting or structure based on the source should be smoothed out. The very first step towards this data integration goal, however, involves abstracting the initial data connections themselves — a complex task when accounting for the number of data sources accessible via the cloud.

Data sources can differ according to the application or the field in question. Computer applications can have multiple data sources defined, depending on their purpose or function. Applications such as relational database management systems and even websites use databases as primary data sources. Hardware such as input devices and sensors use the environment as the primary data source. A good example is a temperature and pressure control system for a fluid circulation system such as the ones used in factories and oil refineries, which take all related data from the environment or whatever they are monitoring; so the data source here is the environment. Data such as temperature and pressure of the fluid are taken by sensors regularly and then stored in a database, which then becomes the primary data source for another computer application that manipulates and presents this data.

A data source is most commonly used in context with databases and database management systems or any system that primarily deals with data, and is referred to as a data source name (DSN), which is defined in the application so that it can find the location of the data. It simply means what the words mean: where data is coming from.

Therefore, the main purpose of a data source is:

1. abstract database communication
2. to map business models to and from database entities and

When developing a data source for a database, we always need a database wrapper. This is sometimes called a DAO (data access object). The goal of the database wrapper is generally to wrap low level database communication, Like SQL queries. Each database would have its own wrapper which is specific to its API. The database wrapper would then be injected into the data source. Within each of the data source methods, the wrapper methods would be called and mapping from raw database entities to business models would take place