현재 기능이 Post 도메인 하나밖에 없지만 해당 도메인에 기반으로 클린 아키텍처를 적용해보았다. ## 클린 아키텍처(Clean Architecture)란? ![Clean Architecture](/contents/posts/post-clean-architecture/clean-architecture.jpg) 클린 아키텍처는 수많은 컴퓨터 과학자가 생각한 아키텍처 규칙들을 종합해서 만든 다이어그램이다. 관심사 분리가 핵심이며 관심사에 따라 소프트웨어 계층을 분리하는 것이다. 보통 다이어그램의 안쪽으로 갈 수록 고수준의 소프트웨어가 되며 의존성은 반드시 안쪽으로 향해야 한다. 내부의 속한 원은 바깥원의 그 어떤 것도 알 수 없어야 한다. ## Clean Architecture를 적용하게 된 계기 함수의 의존관계가 명확하지 않아서 수정이 필요할 때마다 libraries/post.ts 파일을 정독하다시피 했다. 이 상황이 계속 반복되다보니 아키텍처 설계를 다시 해봐야겠다는 생각이 들어 clean architecture를 적용하게 되었다. ## 설계할 때 가장 먼저 할 일 Clean Architecture를 설계할 때 가장 먼저 해야할 일은 도메인의 엔티티 모델을 추상화하는 것이라고 생각한다. {`export interface IPostEntity { id: string; metadata: PostMetadata; content: Content; }`} post별로 id를 갖고 metadata타입과 content타입을 갖는 키를 만들었다. - metadata는 title, description, category와 같은 post를 설명하는 데이터다. - content는 내용인데 타입을 따로 만든 이유는 md와 mdx에 따라 UI에 표현하는 방식이 다르기 때문이다. ## 기존 소스코드 - [Legacy] Post.getFileInfo {` const getFileInfo = (id: string, category: string[]): FileInfo => { const fullMdPath = path.join(postsDirectory, ...category, \`$\{id\}.md\`); const mdExist = fs.existsSync(fullMdPath); const existFilePath = mdExist ? fullMdPath : path.join(postsDirectory, ...category, \`$\{id\}.mdx\`); const fileContents = fs.readFileSync(existFilePath, "utf8"); const matterResult = matter(fileContents); return { isMdFile: mdExist, matterResult, }; }; `} ### Post.getFileInfo의 책임 - 6~8 - md파일인지 mdx파일인지 확인 - 11 - front matter를 object로 변환 ### 문제점 - SRP를 위반함으로써 1번의 책임만 필요할 때, 2번의 책임만 필요할 때에도 이 함수를 호출하게 된다. - 또한 유지보수할 떄 이 함수에 의존하는 함수들에 어떤 영향을 미칠지 모른다. ### 내가 해결한 방법 - infrastructure 안에 FileHandler를 만들어서 파일의 확장명을 알려주는 함수를 만든다. - front matter를 object로 변환하는 건 파일을 분석해 메타데이터를 꺼내주는 것이므로 이것도 FileHandler안에 만든다. {`export class FileHandler { getFileInfo(rootPath: string): IFileInfo { const fileInfo: IFileInfo = { extension: "", rootPath: "", }; const pathArray = rootPath.split("/"); fileInfo.extension = pathArray[pathArray.length - 1].split(".")[1]; fileInfo.rootPath = rootPath; return fileInfo; } convertFrontMatterToObject(data: string): matter.GrayMatterFile { const matterResult = matter(data); return { ...matterResult, }; } }`} - 2~11 - getFileInfo 함수가 확장명과 파일의 절대경로를 알려주는 책임으로서 파일 정보를 알려주는 책임을 맞는다. - 13~18 - convertFrontMatterToObject 함수가 front matter를 object로 변환해주는 책임을 맞는다. 이렇게 하면 위의 함수의 두 가지 책임을 분리할 수 있다. ## 기존 소스코드 - [Legacy] Post.getPostData {`export const getPostData = async ( id: string, category: string[] ): Promise => { const { matterResult } = getFileInfo(id, category); const processedContent = await unified() .use(remarkParse) .use(remarkGfm) .use(remarkRehype) .use(rehypePrettyCode, { grid: true, defaultLang: "js", theme: "dark-plus", }) .use(rehypeStringify) .process(matterResult.content); const contentHtml = processedContent.toString(); return { id, contentHtml, ...matterResult.data, }; };`} ### Post.getPostData의 책임 - 5 - md, mdx파일의 front-matter를 object로 변환 후 metadata 반환 - 7~19 - unified, remark, rehype을 통해 md을 html로 변환 후 반환 ### 문제점 - metadata만 필요할 때, html 소스만 필요할 때 이 함수를 호출해야함. - 현재 파일을 읽어오는 일이기 때문에 id, category로 파일을 불러오기 위해 fileinfo를 호출해야함. ### 내가 해결한 방법 - front-matter로 변환하는 건 파일을 변환하는 행위이기에 FileHandler에서 한다. - html 소스와 metadata는 post 도메인 데이터의 고유 값을 상징한다 생각해서 repository 패턴을 사용해 postRepository에서 post에서 만들어준다 - html과 metadata를 모두 가져오는 useCase를 만든다. {`export class PostRepository implements IPostRepository { constructor( private readonly directory: string, readonly fileHandler: IFileHandler ) {} async getPostMetadata(rootPath: string): Promise { const postData = await this.fileHandler.readFile(rootPath, { encoding: "utf-8", }); const matterResult = matter(postData); const { data: postMetadata } = matterResult; return { ...(postMetadata as PostMetadata), }; } async getPostContent(rootPath: string): Promise { const fileData = await this.fileHandler.readFile(rootPath, { encoding: "utf-8", }); const { content } = this.fileHandler.convertFrontMatterToObject( fileData as string ); const fileInfo = this.fileHandler.getFileInfo(rootPath); if(fileInfo.extension === "md") { const processedContent = await unified() .use(remarkParse) .use(remarkGfm) .use(remarkRehype) .use(rehypePrettyCode, { grid: true, defaultLang: "js", theme: "dark-plus", }) .use(rehypeStringify) .process(content); const contentHtml = processedContent.toString(); return { htmlContent: contentHtml, } }else { return { mdxSource: content, } } } }`} - 3~6 - 우선 post가 담겨있는 directory를 부여받고 fileHandler도 의존성 주입을 해준다. - 8~17 - getPostMetadata 함수가 metadata를 반환해준다. - 19~49 - getContent 함수가 md, mdx인지에 따라 content 데이터를 반환해준다. {`export class PostUseCase { constructor(private readonly postRepository: IPostRepository) {} async getPostDataByIdAndCategory( id: string, category: string[] ): Promise { const { path: { rootPath }, } = this.postRepository.getPostFileInfo(id, category); const promiseMetadata = this.postRepository.getPostMetadata(rootPath); const promiseContent = this.postRepository.getPostContent(rootPath); const [metadata, content] = await Promise.all([ promiseMetadata, promiseContent, ]); return { id, metadata, content, }; } }`} - useCase에서는 repository에 의존하며 getPostDataByIdAndCategory라는 함수를 만들어 Post entity를 최종적으로 만들어준다. 이렇게 repository 패턴을 사용해 데이터의 고유 값을 가져오는 계층을 만들고 두 가지 책임을 분리해 method를 만들어 함수의 문제점을 해결한다. ## 기존 소스코드 - [Legacy] posts/[...path]/page.tsx {`const parsePath = (path: string[]) => { let id: string = ""; const category: string[] = []; if (path.length <= 1) { id = path[0]; } else { id = path[path.length - 1]; category.push(...path.slice(0, path.length - 1)); } return { id, category } } export default async function Post({ params }: { params: { path: string[] }}) { const { path } = params; const { id, category } = parsePath(path); const postData = await getPostData(id, category); return ( <>

{postData.title as string}

) }`} ### 문제점 - 1~13 - parsePath라는 함수가 UI 계층에 같이 있는게 보기 안 좋다. - 14~26 - UI 계층에서 path를 파라미터로 받은 걸 그대로 데이터 가져오는데 사용하지 않고 parse를 한 번 하고 데이터를 가져오는게 불편했다. ### 내가 해결한 방법 - presenter를 하나 만들어서 path를 파라미터로 받고 useCase를 의존하고 getPostDataByIdAndCategory 함수를 호출한다. {`export class PostPresenter { constructor(private readonly postUseCase: PostUseCase){} async getPostDataByRoutingPath(routingPath: string[]): Promise { let id: string = ""; const category: string[] = []; if (routingPath.length <= 1) { id = routingPath[0]; } else { id = routingPath[routingPath.length - 1]; category.push(...routingPath.slice(0, routingPath.length - 1)); } return await this.postUseCase.getPostDataByIdAndCategory(id, category); } }`} - 2 - poseUseCase를 의존한다. - 5~15 - parsePath의 로직을 그대로 넣고 usecase에 id와 category를 파라미터로 넣는다. ## 의존성 주입 지금까지 만든 infrastructure, repository, useCase, presenter들을 한 곳에서 의존성 주입을 한다. 처음에 말했던 것처럼 바깥쪽에서 안쪽으로 주입해야 한다. ### 1. InfraStructure 가장 바깥쪽인 infrastructure부터 만들어준다 {`import { FileHandler } from "@/adapters/infrastructures/FileHandler"; export interface IInfrastructures { fileHandler: FileHandler; } export default (): IInfrastructures => ({ fileHandler: new FileHandler(), });`} ### 2. Repository instrastructure를 의존하고 post directory를 정의해 repository를 만들어준다. {`import { PostRepository } from "@/adapters/repositories/Post"; import path from "path"; import { IInfrastructures } from "./infrastructures"; const postDirectory = path.join(process.cwd(), "src/contents/posts"); export interface IRepositories { postRepository: PostRepository; } export default (infrastructures: IInfrastructures): IRepositories => ({ postRepository: new PostRepository( postDirectory, infrastructures.fileHandler ), });`} ### 3. UseCase repository를 의존하는 usecase를 만들어준다. {`import { PostUseCase } from "@/domain/useCases/Post"; import { IRepositories } from "./repositories"; export interface IUseCases { postUseCase: PostUseCase; } export default (repositories: IRepositories): IUseCases => ({ postUseCase: new PostUseCase(repositories.postRepository), });`} ### 4. Presenter useCase를 의존하는 presenter를 만들어준다. {`import { PostPresenter } from "@/adapters/presenters/Post"; import { IUseCases } from "./useCases"; export interface IPresenters { postPresenter: PostPresenter; } export default (useCases: IUseCases): IPresenters => ({ postPresenter: new PostPresenter(useCases.postUseCase), });`} ### 5. DI 이제 모든 레이어에 의존성 주입을 해줌으로써 하나의 도메인을 완성한다. {`import infrastructures from "./infrastructures"; import presenters from "./presenters"; import repositories from "./repositories"; import useCases from "./useCases"; const createdInfrastructures = infrastructures(); const createdRepositories = repositories(createdInfrastructures); const createdUseCases = useCases(createdRepositories); const createdPresenters = presenters(createdUseCases); export default { post: createdPresenters.postPresenter, };`} ## 마무리 클린 아키텍처가 왜 클린 아키텍처인지 적용하면서 알 수 있었다. 직접 구현하기 전에는 추상적이라 와닿지 않았었다. 사실 처음에 적용할 때도 '이게 맞는건가?' 하는 생각도 많이 들었다. 그런데 김영한(전 배민 기술이사)님께서 "추상화와 구체화의 반복이다" 라는 말이 와닿아서 일단 해보자는 생각으로 해봤다. 물론 앞으로도 추상화와 구체화의 반복이겠지만 새로운 기능이나 유지보수를 할 때 어느 계층에 넣어야할 지 정리가 된 것 같아서 상당히 만족스러웠다. 또한 이전보다 많이 나아졌지만 지금이 최고라고 생각하지는 않는다. 누군가 이렇게 바꾼 걸 보고 다르게 생각할 여지도 있다고 생각한다. 나 또한 아직 만족스럽지 못 한(md, mdx content가 repository에서 받아오는게 맞는지) 부분이 있다. 고민해보고 또 수정할 예정이다. **참조** - [추상화와 구체화의 반복이다.](https://www.youtube.com/watch?v=_HTj5b59Em0&t=14s) - [클린 아키텍처](https://product.kyobobook.co.kr/detail/S000001033082) - [falsy/react-with-clean-architecture](https://github.com/falsy/react-with-clean-architecture)