전제 아키텍처

Presentation

표시를 담당하다

리포지토리

외부와의 접속을 담당한다.

Usecase(Application)

Repository 계층, Store 계층과의 연결.
Repository 계층에서 가져온 데이터를 Store에 저장합니다.
비즈니스 사용 사례 작성.

Entity

모델. (DDD에 넣을 수있는 도메인 모델링)

Query

Store 레이어에서 검색된 데이터를 편집하고 검색합니다.

개발 언어, 프레임 워크

Typescript, Angular

곤란한 일·대책

Presentation편

Component해 나가지만, 재이용성이 없는 것도 Component화해 가는지 헤매었다.

예

「Google 검색」, 「I'm Feeling Lucky」라고 쓰여진 Button은 재이용성이 있으므로, Component화하자.

Google 로고가 구성 요소인지 망설임

대책

하나의 화면이 있는 Component와 재이용성이 있는 Component로 나누었다.

├── modules
    ├── GoogleLogoComponent
└── pages
    ├── GoogleLogoComponent

참고
htps // ch. 비 t 반 k. c / 데시 gnsys me

Entity편

엔티티, 값 개체를 작성할 때, 독특하고 유행하는 같은 설명은 프런트 엔드에서 코스파가 나쁘다,,?

export class ValueObject {
  private _value: string;
  constructor(value: string) {
    this._value = value;
  }

  get getValue(): string {
    return this._value;
  }

  set setValue(value: string) {
    this._value = value;
  }
}

위에서 설명한 것처럼 하나의 객체를 표현하는 데에도이 설명이 필요합니다.
따라서 기본적으로 프런트 엔드에서는 하나의 도메인 객체에서 도메인 로직이 적은 경우가 많습니다.

대책

묘사를 interface에 체재했다. Validation등의 기술은 같은 파일에 function로서 기술.

export interface ValueObject {
  value: string;
}

export function isExist(value: ValueObject): boolean {
  return this.value ? true : false;
}

값 객체에 관해서는 캡슐화해야 하는가?

예
UserId와 같은 값 객체는 store 등의 라이브러리와 궁합이 나쁘다.
( userId: string | number 를 상정하는 경우가 많다)

export interface UserId {
  value: string;
}

대책

uid와 같은 값 객체는 라이브러리와의 궁합의 나쁜 것을 감안해, type에서 string와 동렬인 형태로 했다.
이것에 의해, 인수를 나타낼 때 등에, 가시화는 할 수 있게 되었다.

export type UserId = string;

Query

query 처리가 번잡해지기 쉽다.

단지 api에서 fetch한 JsonData를 사용하여 query를 처리하는 것은 어렵게 되기 쉽다.

대책

정규화함으로써, RDB와 같이 query 처리를 기술할 수 있다.

참고
htps //w w. s에서 멋지다. 네 t/아야타 s0623/레즈 xs 갓-129830690

스토어

store의 분할 단위는 Page 단위? 도메인 객체 단위? ? ?

하나의 page에서는, 복수의 도메인 오브젝트를 취급하는 경우가 많다. 따라서, 도메인 오브젝트 단위로의 Store의 설계라면, 취급하는 Store도 많다. 반대로 Page 단위로 Store를 구성하는 것으로, Store의 취급이 Page 중에서 한정적으로 되지만, 취급하기 쉬워진다.

대책

현재 도메인 개체 단위입니다. 다만, 이런 명확한 이유는 없기 때문에 베스트 프랙티스를 모색중입니다.

참고
htps : // 이 m / 어이 5 u / ms / 4 2c5bc1d546 1b1c5d

Usecase

데이터를 얻는 것은 어디의 책임입니까?

데이터 취득하는 장소는 사용하고 있는 프레임워크, 라이브러리 등으로 상당히 헤어지기도 한다. 예를 들어 Vue.js의 경우는 Vuex를 Store에서 사용하는 경우가 많지만, Vuex의 액션에서는 비동기 처리가 추천되고 있다.

참고
htps : // ㅔ에 x. 아 js. rg/쟈/구이데/아c치온 s. HTML

즉, Presentation에서 발화하고 Action을 Dispatch. 거기서 비동기로 API를 발화시켜, 뮤테이션에 값을 보내는 형태가 되고 있다. 다만, 라이브러리에서 추천되고 있다면 아직도, Store에서 Repository를 취급하는 것은 어떨까 궁금해했다.

대책

InitializeUsecase로서, Usecase 층에서 처리를 행한다.

export class InitializeUsecase {
  constructor() {}

  exec() {
   const repository = new EntityRepository()
   const entity = repository.fetch()
   const store = new Store()
   store.dispatch(entity)
  }
}

마지막으로

자신이 프런트 엔드 DDD를 할 때 곤란한 곳을 얽혀 정리했습니다. 누군가의 도움이되면 다행입니다.