Domain

Domain helps upport the process of improving or automating the business process.

A domain can be separated into a lower level domain to link to other lower level domains to provide the entire process.

• Domain: ordering, users, benefits, payment, delivery, categlog, review
• Lower level domain: customer -> order product -> payment -> delivery -> benefits

Domain Model

The domain model refers to the process or map that includes the useful characteristic. The domain model is a model that conceptually orders a certain domain.

Types of domain modeling:
1. Entity (엔티티)

• A key class linked to the actual DB table. The table is made and the DB schema is change using the entity
• The entity cannot be used for a request or response
• The entity stays the same even when the interal properties are changed
• It is important to define which element has a unique, distinguishable entity (for example, the userId of the User class)

2. Value object (값 객체)
3. Domain service (도메인 서비스)

Architecture Pattern

The architecture pattern is the most fundamental foundation to structure a software.

The architecture pattern defines each system and its function.

Top architecture patterns:

• Repository pattern (저장소 패턴): Abstraction of the permanent database
• Service layer pattern (서비스 계층 패턴): A pattern to clearly declare the start and end of the usecase (유스 케이스)
• Unit of work pattern (작업 단위 패턴): Provides the unit operation
• Aggregate pattern (애그리게이트 패턴): Pattern to improve data matching

Things to consider before introducing an architecture pattern:
1. There must be a clear reason as to the benefits and costs of the architecture pattern
2. Clearly understand what pros and cons exist for an architecture pattern
3. Introduce an architecture pattern if the application and domain are too complicated enough to justify the effort and time invested in adding several classes

Layered Architecture Pattern (계층형 아키텍처 패턴)

One of the most common architecture pattern that separates into layers.

It is simple, popular, and comparatively costless and is pretty much the standard architecture.

The pattern is to separate and maintain in layers and the goal is for every layer to only depend on the layer below it.

The key of layering is to have high cohesion (응집도) and have low coupling (결합도).
You can design a upper and lower layer but the lower layer cannot know what its upper layer or use the upper layer.

Pros of the layered architecture pattern:

• The code that is being made can be clearly recognized when separated into layers of interest
• Every layer has low dependency with each other, allowing to easily edit code when the module is changed
• Every layer can be tested on its own to easily create a test code

3-Layered Architecture (3계층 아키텍처)

The three layers of the 3-layered architecture is as follows:
1. Presentation layer (프레젠테이션 계층)
2. Business logic layer (비즈니스 로직 계층)
3. Data access layer (데이터 엑세스 계층)

The 3-layered architecture uses the following three processes:

1. Controller (in presentation layer): Is the outermost part of an application and processes requests and responses.

2. Service (in business logic layer): The middle part of the application where actual important processes usually take place. This is where the key part of the architecture, business logic, runs. It makes a request to the repository if data from the DB is required.

• Pros:
  - Helps define the use case and workflow
  • Can understand what is the data needed from the repository
  • Can understand what preliminary inspection and current status verification are needed
  • Can understand what information need to be saved
  • The business logic is hidden behind the API that allows to freely refactor the code in the service layer
  • Combining this with the repository pattern and a fake repository allows to create a test of a high standard
• Cons:
  - The service layer is just another abstract layer
  • If there are too many functions in the service layer, an anti-pattern may be created, similar to the anemic domain model (빈약한 도메인 모델)

3. Repository (in data access layer): The innermost part of the application that connects to the DB. This is where the data from the actual DB is used, including managing DB and DB CRUD processes.

• Pros:
  - A fake repository to perform unit tests can easily be performed as the model and infrastructure are completely separated
  • You can concentrate on business issues if the domain model is created in advance
  • When you would like to change your approach, you can apply changes to the model instead of concerning foreign keys and migrations
  • You can control the process of mapping the object to the table to simplify the DB schema
  • When you use ORM in the repository layer, it becomes easier to change DB from MySQL to Postgres
• Cons:
  - The ORM helps alleviate combinations (of models and repositories), even if there is no repository layer
  • Manually mapping the ORM (such as Sequelize) increases development costs

Process flow:
1. The client makes a rquest
2. The controller receives the request according to its URL.
3. The controller calls the service to process the request.
4. The service requests data from the repository to get the required data.
5. The service processes the data from the repository, then sends the data to the controller.
6. The controller sents the resulting response from the service to the client.