Domain

The expression domain is occurring in software bibles for a very long time now and is heavily discussed in the book Domain-Driven Design by Eric Evans. The domain is the real-world context that you are attempting to solve by writing a piece of software. Simply said, the domain is the thing why software exists and is about.

Evans divides the domain into three subdomains.

Core Domain

The core domain represents a competitive advantage and the software’s reason for being. It is a hearth of the software with the most fundamental business rules, use cases, and domain models. It usually is the smallest part of the codebase. In other words, it is the most critical 20% part of the software.

Supporting Domain

Supporting domains are supporting subsystems of software. The core can still exist without them but does not make it alone to its users. There can be multiple supporting domains in one system. For example, the supporting domain is for the core domain, the same thing as invoicing for Amazon.

Generic Domain

A generic domain is the least custom part and the least important part of the software. It is not specific to your domain, and it is widespread in other systems. I am currently working on an employee’s timesheets information system, and the generic domain for this software is an external time tracker for each of the employees.

Summary

It is important to decide what your core domain is and focus your development resources here from a business perspective.

Domain-Centric Architecture

Now when we know what the domain is, you can logically derive that Domain-Centric Architecture puts the domain into the center. Each software architect has a huge responsibility for proper recognition of what is an essential use case and what is just an implementation detail.

Let’s pretend that you are buying the house. What is essential for your choice, and what is in second place?

From my perspective, space and usability are the most fundamental reasons for buying a new house. Ornamentation and building material may come right after that and change my decision, but when I am looking at real estate offers online, I am looking at the space and usability for my needs first.

Hexagonal Architecture

Alistair Cockburn invented hexagonal Architecture in 2005. Also known as Ports and Adapters Architecture. Few authors marked Hexagonal Architecture as the origin of Microservices Architecture.

It is a plug-in system that consists of multiple loosely coupled components which you can connect to the core. The advantage of such division is in easy exchange of each component.

Components communicate with each other via exposed public interfaces(ports). Such interfaces are typically used for notifications or database querying and storing.

Adapters are the glue between components and the outside world. More adapters can be glued to one port. For example, Azure deploying can be managed through CLI, web portal, or Windows PowerShell.

Onion Architecture

Founded by Jeffrey Palermo in 2008. The perspective of Onion architecture is to provide better testability, maintainability, and dependability. It is an architecture based on the Inversion of Control Principle. It is biased towards Object-oriented programming.

The architecture consists of multiple concentric layers interfacing towards the core domain, moving all coupling towards the center.

Domain Layer

In this layer, you will find all business and behavioral objects. It also contains the domain interfaces. The domain layer can’t have any dependency. On the contrary, other layers should depend on the domain layer.

Repository Layer

This is an abstraction for saving and retrieving data from persistence. The layer is also mapping data from persistence to business entities.

Service Layer

Consists of interfaces of common operations. It provides and encapsulates the communication between the UI Layer and Repository Layer. Also, it can hold a business logic for an entity.

UI Layer

This is the most outer layer. Here you will find the implementation of the dependency injection principle. It can be a web application, unit test project, or web API.

Pros

• Flexible, sustainable, and portable architecture.
• No need to create a common and shared project.
• It can be quickly tested.
• Coupling towards the center.

Cons

• It is not an easy architecture for beginners.
• Interfaces and abstractions are heavily used, and moving through code can be confusing.
• Architects mostly messed up, splitting responsibilities between layers.

Clean Architecture

Robert C. Martin, also known as Uncle Bob, invented Clean Architecture in 2012. The architecture is based on the Separation of Concerns principle. It's achieving separation by dividing the software into layers. The architecture is easily testable, independent of UI, database, or any external agency.

The architecture consists of concentric circles that differ in areas of software. The more outer the circle is, the higher level of software it is. Outer circles are mechanisms, and inner circles are policies.

Source code dependencies can only point inwards. Anything declared in the outer circle must not be mentioned in the inner circle, including classes, functions, and variables.

Entities

The Entities layer encapsulates business rules. It can be an object with methods or a set of data structures and functions. It encapsulates the most general high-level rules, also known as Domain.

Use cases

These are application-specific business rules. Here you implement all of the use cases of the system. Rules do not affect the entities. The layer is not affected by externalities such as database or UI.

Interface adapters

This layer is responsible for converting data from use-cases and entities to format for an external agency. Typical usage is the MVC architecture of GUI. Here is where data is converted from Entities to database tables vice versa. The layer's main goal is a conversion from an internal form of data to an external form.

Frameworks & Drivers

The outermost layer. It is composed of glue code for every external agency, such as a database or web framework.

Summary

Each of the listed architecture works the same. They all have the Domain in the center wrapped by Application Layer as use-cases, and Persistence, Presentation, and Infrastructure in the outer circle represent the implementation details pointing towards the center.

Pros

• Heavy focus on the domain.
• Less coupled.
• Allows using Domain-Driven Design.

  Cons

• Change is difficult.
• Requires more thought.
• Initial higher cost.

Sources

• The original blog post about Hexagonal Architecture by Alistair Cockburn.
• Blog post about onion architecture by Jeffrey Palermo.
• Understanding Onion Architecture by CodeGuru.
• Uncle Bob’s 2012 blog post about Clean Architecture.
• Pluralsight course Clean architecture patterns, practices, and principles
• Hexagonal architecture on Wikipedia).
• Stackoverflow answers the question — What is Domain.
• CodeGuru article about Onion architecture.