Database

DB 모듈의 인터페이스와 서비스 레이어를 만들었으므로, 실제 구현체를 만들어야 한다. 우선 인 메모리(In-Memory)로 가볍게 구현체를 만들었다. 인 메모리 데이터 저장소 인 메모리 방식을 선택한 이유는 첫째로 처음부터 SQL이나 JSON 파일 기반 저장소를 이용해서 구현체를 만드는 것 보다는, 가장 단순한 구현체를 만들어서 DB 기능을 검증하고 빠르게 다음 기능을 만들기 위해서이다. 외부 의존성도 없고, 설정도 필요 없고, 테스트도 쉽다. 구현하기 RecordStore 인터페이스를 다시 보면 다음과 같다. export interface RecordStore { list(collection: string): Promise<StoredRecord[]>; get(collection: string, id: string): Promise<StoredRecord | undefined>; create(collection: string, data: RecordData): Promise<StoredRecord>; replace(collection: string, id: string, data: RecordData): Promise<void>; delete(collection: string, id: string): Promise<boolean>; } 구현체는 이 계약을 그대로 만족하면 된다. 중요한 것은 구현체는 Express를 몰라야하고 순수하게 TypeScript 코드로 짜여야 한다. HTTP 요청이나 라우팅 같은 것은 Router가 책임져야 한다. ...

시스템 모듈을 만든 이후에, 아마도 가장 많이 쓰게 될 DB 모듈을 만들었다. 당시에는 구조도 시스템 모듈과 동일하다고 생각했다. Router가 DB 인터페이스에 의존하고, 이를 구현한 구현체를 주입받는 방식으로 DIP와 DI를 동시에 적용했다. 이 과정 중에서 naming bias 해결하기 id 생성 책임 위치 기존 아키텍처의 문제점 -> 서비스 레이어 도입해서 해결하기 에 대한 고민을 했다. 아래는 고민과 해결 과정이다. CRUD부터 만들기 Mock Server라도 최소한 CRUD는 제공해야 한다. 처음부터 구현체를 만들 필요는 없으므로, 라우터와 인터페이스까지만 만들도록 프롬프트를 작성했다. ...