Types of Architecture

Why is application architecture necessary? Architecture determines the structure of an application and the way its components are organized, and provides a blueprint that allows developers to know what standards to use when creating an application. The architecture typically consists of UI, business logic, data access layer, and infrastructure. Building a good architecture means establishing a structure that makes it easy to understand the core functions of the application through the domain. And it creates maintenance and code uniformity by having common rules with team members.

Types of architecture

It can be broadly divided into monolithic architecture and distributed architecture. Monolithic Architecture It is a large-scale single computing network with one code base. It is mainly useful for code management and distribution when developing small applications. However, the downside is that the entire stack needs to be updated. Types include Layered Architecture, Clean Architecture, and Hexagonal Architecture. Distributed Architecture

The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. [Martin Fowler] It is an architecture designed to divide a software system into several independent components, and for these components to operate in a distributed environment and communicate with each other. Service Oriented Architecture, Event-based Architecture, and MicroService Architecture (MSA) are examples of distributed architecture.

Von Neumann Architecture

Computers developed based on the von Neumann architecture, which established a general-purpose computer architecture with CPU, memory, and program structures. A traditional architectural form of a computer system, essentially a monolithic architecture. An architecture that can be applied to distributed systems can improve scalability and availability. How it works When a user inputs a value into the computer or runs a program, the information is first stored in memory, and the CPU sequentially interprets and calculates the information and delivers the result to the user.

Layered Architecture

Presentation layer, Domain (Business or Service) layer, Data Access (Persistence or Infrastructure) layer A layered architecture refers to an architectural pattern consisting of multiple individual horizontal layers that work together as a single software unit. The number of layers can vary depending on the software.

Hierarchy

Presentation Tier This layer handles user interaction and corresponds to Model, View, Controller, and the web layer that knows about HTTP request processing and HTML rendering. Domain hierarchy This layer contains the core logic of the system and is responsible for validation, calculations, and domain-related tasks. Toby's Spring divides it into a service layer and a base service layer. If you look at Dongwook Lee's blog, you can see that it is clearly categorized into a domain layer and a service layer. The domain layer was expressed as a layer purely focused on solving the problem domain based on the Rich Domain model, and the service layer was explained separately as a layer responsible for communication with other infrastructure, such as transactions and mail & SMS sending. What is Rich Domain Model Anemic Domain Model refers to a model in which objects only have data and the business logic required to perform operations is handled by other objects. This refers to a form in which business logic is manipulated by external services or management objects. On the other hand, in Rich Domain Model, the object itself contains business logic, and data and logic operate together. Therefore, compared to the Anemic Domain Model, it has the advantage of reducing redundant business logic and increasing cohesion between objects.

Example of Anemic Domain Model

public class Order {
private int orderId;
private Date orderDate;
private List<OrderItem> orderItems;
// Getter and Setter methods for data fields
public double calculateTotalPrice() {
double totalPrice = 0;
for (OrderItem item : orderItems) {
totalPrice += item.getPrice();
}
return totalPrice;
}
}

Rich Domain Model Example Unlike the example of the Anemic Domain Model,

addOrderItem

removeOrderItem

It also includes methods that perform actions such as

OrderItem

to object

calculatePrice()

Use the method to calculate the price of each order item. Rich Domain Model exists together with data and logic to manipulate data so that objects can manage their own state.

public class Order {
private int orderId;
private Date orderDate;
private List<OrderItem> orderItems;
// Getter and Setter methods for data fields
public void addOrderItem(OrderItem item) {
orderItems.add(item);
}
public void removeOrderItem(OrderItem item) {
orderItems.remove(item);
}
public double calculateTotalPrice() {
double totalPrice = 0;
for (OrderItem item : orderItems) {
totalPrice += item.calculatePrice();
}
return totalPrice;
}
}

Data Access Layer This layer handles database, Message Queue, external API communication, etc.

Problems with hierarchical architecture

Drives database-driven design. Domains are created database-centric, relying on a persistence layer rather than domain-centric. This is because depending on the ORM framework, the direction of dependencies is usually in the persistence layer to which the entities belong. As a result, it has the disadvantage of being modeled based on behavior rather than state changes to the domain model. In addition, since the domain layer is responsible for immediate loading/lazy loading, transactions, etc., there is a problem of creating a strong coupling with the persistence layer. It becomes easier to take shortcuts. The problem of layered architecture is that access from lower layers to higher layers is difficult. So

지름길

As a result, you can adopt the wrong method of lowering the upper component to the lower layer to make it more accessible, thereby making the persistence layer bloated. This

깨진 창문 이론

It is also expressed as a psychological effect. Ultimately, the disadvantage is that as various roles are performed in one layer, separation of concerns is not properly achieved. It becomes difficult to test. I've never created a project like this, but there may be cases where you access the persistence layer directly from the web layer. In that case, layer separation becomes ambiguous, as the role that the domain should play is performed in the web layer, and unit testing becomes difficult. Hide the use case. This can be seen as an extension of the above problem. This vague separation of layers makes it difficult to know exactly where to add functionality when trying to add use cases. Simultaneous tasks become difficult. Collaboration is difficult because it centers around a persistence layer. If the domain or persistence layer becomes large, simultaneous editing may be required during the process, and code conflicts may occur during merging. How to solve the problem In order to solve the problems of the above hierarchical architecture, it is necessary to follow the SOLID principles, which are object-oriented development principles, and apply unit tests to reduce the risk of creating inappropriately wide layers or relying on unnecessary persistence layers.

Clean Architecture Layered Architecture Layered Architecture Anemic Domain Model vs. Rich Domain Model Rich vs Anemic Domain Model Microservice Principles: Decentralized Governance Monolithic Architecture Is Still Worth at 2021 ? Comparison of microservices and monolithic architecture