Go에서 마이크로서비스 구축: 도메인 주도 설계의 서비스

우리의 비즈니스 도메인과 이를 관리하는 규칙에 따라 일부 개념은 기존 엔터티의 일부로 모델링될 수 없는 경우가 있습니다. 이러한 경우 서비스를 도입할 필요가 있습니다.

실제로 오버로드된 용어이지만 Domain Driven Design 컨텍스트에서 서비스는 특정 제한된 컨텍스트의 유비쿼터스 언어로 주장을 정의합니다.

Domain Driven Design Ubiquitous Language는 Eric Evans에 의해 다음과 같이 정의됩니다.

A language structured around the domain model and used by all team members within a bounded context to connect all the activities of the team with the software.

그리고 바운디드 컨텍스트는 다음과 같습니다.

A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable.

Disclaimer: This post includes Amazon affiliate links. If you click on one of them and you make a purchase I'll earn a commission. Please notice your final price is not affected at all by using those links.

서비스는 실제로 어떻게 보입니까?

"To Do Microservice"에 대해 our code을 보면 다음과 같은 service.Task 을 구현했습니다.

// Task defines the application service in charge of interacting with Tasks.
type Task struct {
    repo TaskRepository
}

// Create stores a new record.
func (t *Task) Create(ctx context.Context, description string, priority internal.Priority, dates internal.Dates) (internal.Task, error) { /* ... */ }

// Task gets an existing Task from the datastore.
func (t *Task) Task(ctx context.Context, id string) (internal.Task, error) { /* ... */ }

// Update updates an existing Task in the datastore.
func (t *Task) Update(ctx context.Context, id string, description string, priority internal.Priority, dates internal.Dates, isDone bool) error { /* ... */ }

이 서비스는 TaskRepository라는 Repository을 참조하며, 이는 결국 종속성 주입in main을 통해 할당됩니다.

이 형식의 서비스는 일반적으로 집계를 나타내며 결국에는 단일 단위로 처리될 도메인 개체의 클러스터를 나타냅니다. 이 코드의 향후 반복에서는 Task가 SubTasks 및 Categories 와 같은 다른 항목도 포함할 때 이것이 어떻게 적용되는지 볼 수 있습니다.

이별의 말

서비스 구현은 도메인 개체와 지속성 계층과 같은 일부 외부 종속성 간의 상호 작용을 나타내는 데 유용합니다. 서비스를 구현하는 데 있어 어려운 부분 중 하나는 서비스를 구현해야 하는 시기를 알고 우리 비즈니스에 단일 단위로 모델링해야 하는 특정 프로세스가 있는 경우에 대해 생각해야 하는지 결정하는 것입니다.

"To Do Project"에서 서비스 이름으로 Task를 사용하고 있지만 이것이 의미하는 것은 데이터베이스 테이블이나 모델 작업이 아니라 작업 및 기타 엔터티와 상호 작용하는 프로세스이며 이 모든 것이 단일로 처리됩니다. 물건.

서비스를 이러한 용어로 정의할 때 "우리가 모델링하려는 비즈니스 프로세스는 무엇이며 어떤 엔터티가 관련되어야 합니까?"라는 질문을 하십시오. 이 질문에 답하면 서비스로 모델링할 수 있는 프로세스의 이름을 알 수 있습니다.

계속 유지하십시오. 다음에 이야기하겠습니다.