Software Architecture

Course’s Code: CSE 483

Domain Centric Architecture

(Chapter 6)
 Chapter 6

Chapter 6. Domain Centric Architecture

6.1 What is Domain-Centric Architecture?
6.2 Modern Four-Layer Architecture?
6.3 Types of Domain Architecture?
6.4 Advantages and Disadvantages

11/8/2024 2
 What is Domain?

In software architecture, the domain represents the specific area of

knowledge, activity, or business that a software application is designed to
address. It includes the concepts, processes, and rules central to solving
problems within that area.

For example:

The banking domain includes all the elements:

- Services (wealth management, asset management, money transfer)
- Products (account, loan)
- Transaction
- Customer interaction
- Risk management
11/8/2024 3
 What is Domain Model?
The domain model is an abstraction that defines the entities, their relationships,
and business rules relevant to the domain.

1 1..*
Customer Bank

1
*
1..* 1 1 1..*
Statement Account Transaction

type of

Banking – Domain Model CheckingAccount SavingAccount

11/8/2024 4
 What is Domain Logic (Business Logic)?

Domain Logic refers to the operations, rules, and validations specific

to the domain that define how the application behaves and fulfills its
purpose.

For example:

In banking software, domain logic would cover transfer activities,

transaction management, interest calculation, transaction
validation, and fraud detection..

11/8/2024 5
 Three-Tier Architecture’s dependency direction

Presentation layer takes care for the input/output,

business layer is where we define our domain specific
rules, and the data access layer provides simplified
access to the database.

▪ Presentation layer depends on business layer

▪ Business layer depends on persistence layer

11/8/2024 6
 Three-Tier Architecture’s dependency direction

Dependency

11/8/2024 7
 Problems with Data-Centric Architecture

▪ The business or domain logic is also the most

important part of our solution. It must be stable
and have much less dependency to outside world.

▪ With this diagram, business layer depends on the

persistence layer which cant be independent.

▪ Existing coupling our domain with data persistence

details, which makes it impossible to replace the
database without breaking our domain. Any
change inside persistence layer might cause a
change inside business layer.
11/8/2024 8
 Problems with Data-Centric Architecture

For example:

In banking industry, Symitar core banking

system serves all online banking services with
ability to integrate fintech capabilities quickly
and easily.

The end goal is to be able to migrate from SQL

Server to MySQL without changing anything
inside business layer.
11/8/2024 9
 What is Domain Centric Architecture?

Domain-centric architecture describes

an approach where the heart of our
software is the business (application)
layer and the domain.

To have such architecture, we must

make our business layer independent
from details as the database, it
shouldn't be concerned with the
question where we persist the data
DB
Server

11/8/2024 10
 Database-Centric Architecture

A use case – car dealership inventory

system

Use ASP.NET Core 3.0 application

• CarsController (Presentation Layer) has

POST action to add new car.

• We pass data to CarService (Business

Layer)

• CarService validates data and use

CarRepository (Data Access layer) to
write to database.
11/8/2024 11
 Database-Centric Architecture

To persist any data CarService must use

CarRepository (inside our persistence
layer).

That's where the dependency exists

between our business rules and the
data access layer.

Any change in the way we persist cars,

let's say in CarRepository, might cause
a change in our CarService (business
layer)

11/8/2024 12
 Domain-Centric Architecture

In Domain-centric architecture is to inverse

dependencies towards the application layer.
Dependency Inversion Principle
The dependency inversion principle (DIP) states that high-
level modules, which implement the business logic, should
not depend on low-level modules.

High-level modules should not depend on low-level modules. Both should depend
on abstractions.
Abstractions should not depend upon details. Details should depend upon
abstractions.

11/8/2024 13
 Domain-Centric Architecture

Presentation
Let’s add an application layer as a façade for the system’s
public interface. It describes all the operations exposed by
the system.
Application
Now Business layer is broken down into Domain Layer and
Application Layer.
Business

The application layer is a logical boundary. It is not a

Domain
physical service. The application layer acts as a façade for
the business logic layer: it exposes interfaces.

Persistence
11/8/2024 14
 Domain-Centric Architecture

A new ICarRepository interface is created in

application layer.

The implementation CarRepository is in

persistence layer.

11/8/2024 15
 Domain-Centric Architecture
Now CarService in Domain layer will extract ICarRepository inside the application
layer and the implementation CarRepository is done inside the persistence layer.

If we decide to replace SQL Server database with MySQL, we must change or create a
new implementation in persistence layer.

11/8/2024 16
 Database-Centric vs. Domain-Centric Architecture

(use cases)

DB Server

11/8/2024 17
 Essential vs.Detail

Space is essential

Usability is essential

Building material is a detail

Decoration is a detail

11/8/2024 18
 Essential vs.Detail

Domain is essential
(use cases)
Use cases (Business) is essential
Presentation is a detail
Persistence is a detail
Infrastructure is a detail
DB Server

11/8/2024 19
 Database-Centric vs. Domain-Centric Architecture

Dependency
Dependency (use cases)

DB Server

11/8/2024 20
 Chapter 6

Chapter 6. Domain Centric Architecture

6.1 What is Domain-Centric Architecture?
6.2 Modern Four-Layer Architecture?
6.3 Types of Domain Architecture?
6.4 Advantages and Disadvantages

11/8/2024 21
 Modern Four-Layered Architecture

• Disadvantages of three-tier architecture

• Where should abstraction be located?

Presentation

Business

Persistence
11/8/2024 22
 Modern Four-LayerModern Four-Layered Architectureed Architecture

User
• Similar to Three-Tier architecture
Presentation
• Application encapsulates use cases
Application
• Application layer dependent on Domain
Domain
• Domain layer contains business rules
Persistence Infrastructure
• Persistence layer gateway to database
Database OS

11/8/2024 23
 Modern Four-LayerModern Four-Layered Architectureed Architecture

11/8/2024 24
 Modern Four-Layered Architecture

Advantages
▪ Separation of concerns

▪ Focus on Use Case

▪ Easy to understand

▪ Follow Dependency Inversion principle (facilitates dependency

injection)

11/8/2024 25
 Modern Four-Layered Architecture

Disadvantages
▪ Add layer cost

▪ Require extra thought

11/8/2024 26
 Domain-Driven Design

Domain-Driven Design is a major software design approach, focusing on modeling

software to match a domain according to input from that domain's experts (people
who have deep knowledge in the field).

“Mark Richards, Neal Ford - Fundamentals of Software Architecture_ An Engineering

Approach (2020, O'Reilly Media)“

“Evans, Eric - Domain-driven design_ tackling complexity in the heart of software-

Addison-Wesley (2014)”

“Vlad Khononov - Learning Domain-Driven Design_ Aligning Software Architecture

and Business Strategy-O'Reilly Media (2021)”

11/8/2024 27
 4-Layered Architecture
User Interface / Presentation Layer
It is the interface for interactions with customers (e.g : Web UI, CLI, REST API).
Application / Service Layer Presentation
The service layer functions as a bridge between the
presentation layer and the business logic layer of the
application. Application

Domain Model / Business Logic Layer

This layer is responsible for implementing and Domain
encapsulating the application's business logic. It is Value Objects,
where business decisions are executed. Entities,
Aggregate
Infrastructure / Data Access Layer
This layer integrates the Persistence Systems. In modern Persistence Infrastructure
systems, it can be used for databases (DynamoDB, RDS,
etc.).
11/8/2024 28
 Domain-Driven Design

While dealing with Domain-Driven Design (DDD), developers

often encounter the concepts of :

• Value Objects,

• Entities,

• Aggregates.

11/8/2024 29
 Value Objects
Value objects have attributes, but can’t exist on their own. Value objects are immutable
objects that encapsulate the data. Value objects are immutable, meaning they cannot be
changed once created.

Value Objects

11/8/2024 30
 Entities
Entities are a combination of data and behavior. It encapsulates the data and behavior of its
attributes. It may be convenient to view entities as a collection of other entities and value
objects that need to be grouped together.

11/8/2024 31
 Aggregates
An aggregate has the following qualities:

• Is an entity usually composed of other child entities and value objects

• Encapsulates access to child entities by exposing behavior

• Is a boundary that is used to enforce business invariants (rules) consistently

11/8/2024 32
 Aggregates (cont)
1. The CheckingAccount aggregate is
composed of child entities and value
objects.

2. The tryWithdraw method acts as a

consistency boundary for the
operation. Irrespective of the
outcome (approved or rejected), the
system will remain in a consistent
state. In other words, the
currentBalance can change only
within the confines of the
CheckingAccount aggregate.

3. The aggregate enforces the

appropriate business invariant (rule)
to not allow overdrafts to withdraw.
11/8/2024 33
 Chapter 6

Chapter 6. Domain Centric Architecture

6.1 What is Domain-Centric Architecture?
6.2 Modern Four-Layer Architecture?
6.3 Types of Domain Architecture?
6.4 Advantages and Disadvantages

11/8/2024 34
 Types of Domain Centric Architecture

Three Domain-Centric variants

1. Hexagonal Architecture

2. Onion Architecture

3. Clean Architecture

DB
11/8/2024
Server
35
 Hexagonal Architecture
▪ Introduced by Alistair Cockburn in
2005

▪ Cockburn states following goals:

• The business logic should be able to

be developed and tested in isolation
from the database, other
infrastructure. It makes no difference
whether data is stored in a relational
database, a NoSQL system…

• Infrastructure modernization (e.g.,

upgrading the database server,
upgrading insecure libraries) should
be possible without adjustments to
the business logic.
11/8/2024 36
 Hexagonal Architecture

• Called Port-Adapter Architecture

• This architecture divides an application

into two parts namely, the Inside part
and the Outside part.

• The core logic of an application is

considered as the Inside part. The
database, UI could be the Outside part.

• The core application logic has been

isolated completely from the outside
world.

11/8/2024 37
 Hexagonal Architecture
• The communication between Inside
part and Outside part can happen
through Port and Adapters.

• Port: Interface

• Adapter: Implementation of Port

• The business logic (“application”) is at

the core of the architecture. It defines
interfaces (“ports”) to communicate
with the outside world.

• The business logic knows only these

ports.
11/8/2024 38
 Control Flow
Application which:

• is controlled by a user via a user

interface

• is controlled by a user via a REST API

• is controlled by an external application

via the same REST API

• controls a database

• controls an external application.

The connection to the external components is provided by “Adapters.”

11/8/2024 39
 Control Flow
For example, the user interface could provide a registration
form. User fills data and clicks “Register,” the UI adapter
generates a “Register User” command and sends it to the
business logic. The same command could be generated by the
REST adapter for a corresponding HTTP POST request.

11/8/2024 40
 Control Flow
On the “other side” of the application, the database
adapter could translate the “Save User” command into
an “INSERT INTO User VALUES (…)” SQL query

11/8/2024 41
 Control Flow
Several adapters can be connected to one port.

For example, as in the example above, a user interface adapter and a REST adapter
can both be connected to the port to control the application

11/8/2024 42
 Ports
Ports act as gateways for communication,
functioning as either inbound or outbound ports.

Two types of ports – those that control the

application and those that are controlled by the
application.

Inbound ports (driving ports) : shown on the left

side of the hexagon. Is an interface, exposes the
core logic to the outside world.

Outbound ports (driven ports): shown on the

right. Is an interface, enables communication from
the application to a persistence system

11/8/2024 43
 Adapters
Adapters function as implementations of ports,
handling user input and converting it into language-
specific commands. They contain the logic for
interacting with databases, facilitating communication
between external entities and the core logic.

Two types of adapters – those that control the

application and those that are controlled by the
application.

Driving Adapters : drive the application using its

inbound port.

Driven Adapters: implement outbound ports and are

driven by the application (e.g: databases (DynamoDB
adapter).
11/8/2024 44
 Dependency Rule
Dependency Rule: all source code dependencies may only point from the outside
inwards

11/8/2024 45
 Dependency Rule with Driving “Port-Adapter”
The RegistrationController is the adapter, the RegistrationUseCase is the interface, and
the RegistrationService in Domain layer implements the functionality described by the
port.

The source code dependency goes from RegistrationController to RegistrationUseCase,

therefore, as required, towards the core.
11/8/2024 46
 Dependency Rule with Driven “Port-Adapter”

The source code dependency must be opposite to the invocation direction? How can
the application core access the database if the database is outside the core and the
source code dependency is to be directed to the center?

11/8/2024 47
 Dependency Rule with Driven “Port-Adapter”

This is where the dependency inversion principle comes into play.

High-level modules should not depend

on low-level modules. Both should
depend
on abstractions.

Abstractions should not depend upon

details. Details should depend upon
abstractions

11/8/2024 48
 Dependency Rule with Driven “Port-Adapter”
The PersistanceAdapter does not use the PersistencePort but implements it. And the
RegistrationService does not implement the PersistencePort but uses it

Employing the
dependency inversion
principle, we can choose
the direction of a code
dependency –opposite to
the calling direction.

11/8/2024 49
 Benefits of Hexagonal Architecture
• Testability: Isolating the application and business logic from external factors so that
they can all be tested easily and separately.

• Application work without any technology: Designing the user interfaces by their
purpose rather than technology ensures that your application’s technology stack can
freely grow over time.

• Scalability: The ports and adapters are just as replaceable as all the external entities,
further contributing to the scalability of the entire application.

• Maintainability: The advanced separation of concerns also makes the app easier to
maintain, as changing the code in one place or adding new dependencies/ways to
interact with the app, do not require significant code changes.

11/8/2024 50
 Onion Architecture

Introduced by Jeffrey Palermo in

2008.

It emphasizes the use of

interfaces for behavior
contracts, and it forces the
externalization of infrastructure.

The Onion Architecture relies

heavily on the Dependency
Inversion principle.

11/8/2024 51
 Key Principles of Onion Architecture

1. The application is built around an

independent object model Inner layers
define interfaces.

2. Outer layers implement interfaces

3. Direction of coupling is toward the center

4. All application core code can be compiled

and run separate from infrastructure

11/8/2024 52
 Layer Description

1. Domain Model.
• the innermost layer of the architecture.
• they represent the business models,
containing the business rules from it’s
domain.

public class Account {

private balance;
private User owner;
private Transaction[] transactions;

//domain logics
public void withdraw(double amount);
public void deposit(double amount);
}
11/8/2024 53
 Layer Description

2. Domain Services.

• There are some cases where it’s hard to fit a

behavior into a single domain model.

For example:
In banking system, Transfer feature involves 2
Accounts but it’s not clear if we implement it in
Account Model. So we will implement it in
Domain Services.

public class BankService {

//business logic
public bool transfer(Account source, Account destination, double amount)
11/8/2024 } 54
 Layer Description
3. Application Services.

• referred as “Use Cases” or Application rules.

• application rules different with business rules.

Example of Application rule:

To withdraw, first pull account from DB, then call
withdraw method in account domain model, then
save back to DB
//use case
public void accountWithdaw(AccountService acctS, String accountID, double amount){
//get Account from DB
//account.withdraw(amount);
//save Account back to DB
11/8/2024 } 55
 Layer Description
3. Application Services (Cont).

• It also declare some interfaces with methods

to connect to data repository.

11/8/2024 56
 Layer Description

4. Infrastructure Layer.

• the outermost layer of the architecture.

• referred as “adapters”
• responsible for implementing all the IO
operations.
• know about everything contained in the inner
layers.
• not implement any business logic, as well as
any use case

11/8/2024 57
 Benefits of Onion Architecture

• Testability: Clear separation of concerns makes individual components

easier to test in isolation.

• Flexibility: Changes in one layer typically don't affect other layers,

promoting easier maintenance and updates.

• Scalability: As the application grows, the structure accommodates new

features without drastic changes.

11/8/2024 58
 Clean Architecture

• Introduced by Bob Martin in 2012.

• Its core is the same as Onion or

Hexagonal architecture: DIP-based

11/8/2024 59
 Clean Architecture’s Layers
1. Entities layer

• encapsulate business rules.

• this layer knows nothing

about the other layers, which
means entities don’t depend
on anywhere or anything.

• they may be exist even there

is no application.

11/8/2024 60
 Clean Architecture’s Layers
2. Use Cases layer

• contains application specific

business rules (application rule).

• encapsulates all of the use cases

of the system.

• This layer knows about nothing

about the other layers but the
entity. Use cases layer has
interfaces and or abstract
classes that the other (further)
layers can use.
11/8/2024 61
 Clean Architecture’s Layers
3. Interface Adapters layer

• Retrieve and store data from

and to database.

• Convert data from use cases

and entities for being used by
database.

• Implement the interfaces

defined by the use case.

11/8/2024 62
 Clean Architecture’s Layers
1. Frameworks and Drivers layer

• frameworks and tools such as

the Database, the Web
Framework.

• so likely to change.

11/8/2024 63
 Types of Domain Centric Architecture

All three models follow the same idea

• Domain at the center

• Surrounding with Application layer, presentation, database

and infrastructure

11/8/2024 64
 Chapter 6

Chapter 6. Domain Centric Architecture

6.1 What is Domain-Centric Architecture?
6.2 Modern Four-Layer Architecture?
6.3 Types of Domain Architecture?
6.4 Advantages and Disadvantages

11/8/2024 65
 Advantages of Domain-Centric Architecture

▪ Focus on what’s essential

▪ More maintainable

▪ Presentation, persistence easily changeable

▪ Code more testable

▪ Allows domain-driven design

11/8/2024 66
 Advantages and Disadvantages

Disadvantages
Requires a change in thinking

Higher development cost

11/8/2024 67