DDD Aggregate Root 에 기반한 FSD 의 entities/slice 구성

[toothlessdev]

프론트엔드 폴더구조에 대한 컨벤션을 정하면서 Feature Sliced Design 을 도입하고 있습니다

• Layer : app, features, entities, shared
  • Slice : 각 레이어의 도메인/기능별 단위
    • Segments : components, hooks 등 세부 분류

Feature Sliced Design 은 간단히 말해 위와 같은 방식으로 설계를 하는 방식입니다
각 layer는 app < features < entities < shared 로의 단방향 의존관계를 가지고,
layer 내부의 slice 끼리는 참조를 하지 못하는 구조입니다.

여기서 entities 라는 레이어의 slice 를 어떤식으로 나눌지에 대한 고민을 하고 있습니다

---

이전 프로젝트에서는 entities 안의 slice 들을 RDB 테이블 스키마에 맞게 정의를 해두고 사용하는 방식을 채택했지만,
특정 slice 들이 다른 slice 를 참조하면서 layer 내부의 slice 끼리는 참조를 하지 못하는 구조 를 위반하게 되었습니다

예를들어 잡만리를 예시로 들자면,
entities 의 slice 를 DB 테이블 스키마에 맞게 entities/feed, entities/comment 로 나누는 경우,
comment 가 변경되었을때 feed 의 comment_count 가 변경됨에 따라 서로 참조하는 경우가 발생할것이라 예상됩니다
(낙관적업데이트 등의 로직을 포함한다고 가정했을때)

이를 해결하기위해서 DDD 를 조금 공부하다보니, Aggregate Root 라는 개념을 접하게 되었습니다
외부에서 접근 가능한 유일한 진입점이자, 해당 묶음의 생명주기와 상태 일관성을 책임지는 중심 엔티티로 알고 있는데

이 개념을 프론트엔드 관점에서 바라보면,
entities 레이어의 slice는 개별 테이블이 아니라, 함께 변해야 하는 상태의 경계,
Aggregate Root 단위로 나누는 것이 더 자연스럽지 않을까라는 생각으로 이어졌습니다

위의 예시에서 entities/(slice) 를 Aggregate Root 로 나눈다고 가정을 하면,
entities/comment 와 entities/feed 는 entities/feed 라는 하나의 Aggregate Root (feed) 로 묶이게 되고,
자연스럽게 순환참조문제도 해결됩니다

---

정리해보면, 기존에 사용하던 RDB 테이블 기준의 entities/slice 분리 방식은
프론트엔드에서 다음과 같은 문제를 만들고 있었습니다.

• 하나의 사용자 행동이 여러 entity slice의 상태를 동시에 변경하게 되고
• 결국 entities 레이어 내부에서 slice 간 참조가 발생하게 됩니다

이는 Feature Sliced Design에서 의도한
layer 내부 slice 간 참조 금지 규칙을 구조적으로 어기게 되는 결과로 이어졌습니다.

반면, entities/slice를 Aggregate Root 단위로 정의할 경우,

• 함께 변해야 하는 상태를 하나의 slice에서 책임질 수 있고
• 외부(feature)에서는 Aggregate Root만을 진입점으로 사용하게 되며
• entity 간 순환 참조 없이도 상태 일관성을 유지할 수 있다는 장점이 있다고 판단했습니다

---

현재는 다음과 같은 기준을 하나의 방향성으로 두고 검토 중입니다.

entities/slice는 DB 테이블 기준이 아니라
함께 생성, 변경, 삭제되는 상태의 경계
즉, Aggregate Root 단위로 나눈다

예를 들어,

• Feed가 댓글(Comment)의 생성/삭제에 대한 상태 일관성을 함께 책임진다면
  • Feed를 Aggregate Root로 두고
  • Comment는 해당 Aggregate 내부 상태로 관리하는 방식입니다.

이렇게 구성할 경우,

• optimistic update 낙관적 업데이트
• 여러 화면 간 상태 정합성

등을 하나의 entity slice 내부에서 처리할 수 있게 됩니다

---

논의하고 싶은 지점

1. 프론트엔드에서 entities/slice 의 기준은 무엇이 적절할까요? @eunwoo-levi @kimgho

• DB 스키마
• API 응답 구조
• UI 단위
• 상태 변경 / 캐시 무효화 단위

2. 현재 백엔드에서의 aggregate root 는 어떤게 있나요? @jbh010204 @Sunja-An @BaeJunH0 @polyglot-k

프론트엔드와 백엔드 관점 모두에서의 의견이나 실제 적용 경험을 자유롭게 공유해주시면 감사하겠습니다

[kimgho]

entities/comment 와 entities/feed 는 entities/feed 라는 하나의 Aggregate Root (feed) 로 묶이게 되고,
자연스럽게 순환참조문제도 해결됩니다

저도 comment,feed를 하나로 합치는게 좋다고 생각해요
feed에선 어떤 내용과 댓글 등 여러 정보들이 조합이 되는 형태인데, 이 상황이 feed에 다른 entities들이 종속된다고 보여져서 이걸 독립적으로 둔다고 하더라도 결국 comment의 상태가 변경이 된다면 feed의 상태도 같이 변경되야 할 가능성이 높기 때문이에요
지금은 feed의 예시지만, MVP이후를 생각한다면 이런 고민거리들이 많아질거라 미리 정하는게 좋아보여욥
대신 aggregate를 한다면 프론트쪽에서는 내부에 entities들이 최대한 낮은 결합도와 높은 응집도를 가질 수 있도록 구조를 잡아야할거같아요

[eunwoo-levi]

요지는 DB 테이블 기준으로 entities/feed, entities/comment를 나누면 댓글 추가/삭제 같은 한 액션이 댓글 목록 + feed의 commentCount처럼 여러 slice를 동시에 건드려야 해서 entities 내부 slice 참조 금지(FSD 규칙)와 충돌한다는 것이고, 그래서 FE의 entities/slice는 테이블이 아니라 함께 변해야 하는 Aggregate Root 단위로 잡는 게 더 자연스럽다는 제안으로 이해했습니다!
저도 해당 방식으로 가면 추후에 도메인이 확장됐을 때 의존성을 분리할 수 있을 것 같아서 좋은 것 같아요.

다만 떠오르는 단점으로는, 추후에 feed라는 aggregate 아래에, 특정 도메인 (예: 댓글)만 보고 싶은데 상위 도메인인 feed 디렉토리를 타고, 특정 도메인을 찾아야한다라는 단점이 생길 것 같아요. 이를 해결하기 위해서 entities/feed/comment 이렇게 디렉토리를 한 층 더 분리해야할 것 같은데 어떻게 생각하시나요!!

[kimgho]

말씀해주신대로 features가 entities를 활용하여 행위를 취하는 것이 기본 원칙이며, features/write-comment가 entities/comment와 entities/feed 두 개를 사용하는 구조 자체는 로직상 문제가 없어 보여요

하지만 FSD의 규칙 때문에 문제가 발생할 수 있어요
만약 features/write-comment가 comment를 생성하고, feed의 comment_count를 동시에 업데이트하는 액션을 호출하면
이때, 두 엔티티의 상태를 하나의 일관된 단위로 묶어 관리해야 하는 경우가 발생해요

FSD는 같은 레이어(entities) 내부의 Slice끼리 상호 참조하는 것을 금지하고 있어서
만약 entities/comment의 로직이 entities/feed를 참조하여 상태를 업데이트해야 한다면, 이 규칙을 위반하게 됩니답

[polyglot-k]

entities comment 로직이 entities feed을 참조해야하는 이유를 모르겠습니다. 혹시 설명 가능할까요? @kimgho

[kimgho]

아 위 예시는 fsd 규칙설명을 위한 예시라 실제로 참조는 하면 안됩니다

[toothlessdev]

저도 @polyglot-k 님이 말씀해주신 방법처럼 features 에서 entities 의 상태를 변경하는 유즈케이스에 대해 add-comment, delete-comment 와 같은 사용자 액션에 대한 feature/slice 로 분리하는것도 좋은 방법이라고 생각합니다

다만, 해당 Aggregate Root 의 상태를 변경할때는 DDD 철학을 따라 entnties/slice 로 단일진입점으로 합친다면
각 feature 에서 중복되는 도메인규칙을 단일화 할수 있을것이라는 생각이 들었고 상태의 일관성 보장에 좋을것 같다는 생각이 들었습니다

예를들어 feed 의 comment_count 를 올려야하는 경우가

• feed 목록에서 증가
• feed 상세에서 증가
  두가지가 있다고 가정했을때

각 features 에서 책임지게 된다면 features/feed-list, features/feed-details 에서 각각 comment_count 를 증가시켜야한다는 중복이 발생할 우려가 있다고 생각합니다

그래서 프론트엔드에서도 상태변경 또한 하나의 생명주기라고 생각했을 때, entities가 상태 변경의 규칙과 정합성(캐시 갱신, optimistic/rollback, 예외처리 등)을 책임지는 단일 진입점이 된다면, 각 feature에서는

댓글을 추가한다/삭제한다 같은 유즈케이스의 트리거만 담당하고, 실제로 어떤 캐시를 어떻게 수정할지, 어느 화면에 반영할지 같은 도메인 규칙은 entities로 위임할 수 있어 결과적으로 feature 간 중복 로직을 줄이면서 상태 일관성을 더 안정적으로 보장할 수 있을 것 같다는 의견입니다!

[toothlessdev]

다만 떠오르는 단점으로는, 추후에 feed라는 aggregate 아래에, 특정 도메인 (예: 댓글)만 보고 싶은데 상위 도메인인 feed 디렉토리를 타고, 특정 도메인을 찾아야한다라는 단점이 생길 것 같아요. 이를 해결하기 위해서 entities/feed/comment 이렇게 디렉토리를 한 층 더 분리해야할 것 같은데 어떻게 생각하시나요

@eunwoo-levi
해당부분 같은경우 Comment는 Feed의 Sub-entity(혹은 FeedComment)다 같이
유비쿼터스언어 (팀 전체가 동일한 도메인 개념과 경계를 같은 용어) 로 합의한다면 어느정도 해결이 되지 않을까.. 하는 생각입니다

요렇게 통일한다면 프론트-백엔드 소통간에도 수월할것 같다는생각이 듭니다!

[polyglot-k]

일단 굉장히 긴 글 잘 읽었습니다 :)

일단 프론트 엔드의 구조를 백엔드의 DDD 의 분할 구조를 따라 가고 싶다고 말씀하시는걸로 이해했는데 맞을까요? @toothlessdev

저는 이의 경계를 나누는 것을 Seperate of Concern 의 기준에서 바라보자면, 백엔드의 Aggregate Root 와 FSD Slice 가 1 : 1 로 구조화가 되지 않는 다고 생각합니다.

먼저 백엔드의 경우에는 변경 싸이클의 생명 주기를 함께하는 요소를 동일 Aggregate 로 묶습니다. 즉, 댓글이 변경된다고 해서, 저희는 기존 게시글에 대한 형태가 변경되지 않습니다. 추후에 반정규화로 게시물에 댓글 수에 대한 것을 처리한다면, 동일 Aggregate 로 볼 수 있지만, 현재는 생명 주기를 함께하는 형태는 아니라고 판단했기 때문에 분리해서 놔두었습니다

프론트엔드의 FSD 의 경우에는 화면이나 사용자 행동 중심의 요소로 Slice 가 되며, 이는 꼭 백엔드의 요소와 맞춰질 필요는 없다고 생각합니다! 또한 댓글에 답글까지 고도화 방향성이 잡혀있는데, 그렇게 된다면, Feed, Comment, CommentReply 요소가 모두 같은 형태에 들어가면, 난해해진않은지도 궁금합니다.

---

저희의 경우 Aggregate Root 가 src/main 폴더내에 패키지(폴더) 이름을 Aggregate Root 로 바라봐주셔도 될 것 같습니다!

추가로 궁금하거나 이상한 부분이 있으면 답글 남겨주세요!

[polyglot-k]

• 추가로 slice 를 소모하는 상위 Layer 에서 각 slice 의 인터렉션을 정의하면, 묶을 필요가 없지 않을지 궁금합니다.!

• @eunwoo-levi 님 말처럼 하이라키 구조로 폴더를 늘리게 된다면, FSD 의 3depth(?) 원칙이 깨지고, SoC 기준에서 모호한 지점이 생길 수도 있다는 판단이 드는데 혹시 어떨까요?

[toothlessdev]

답변감사합니다!

feed, feedcomment 로 분리되어있는 패키지 구조를 확인했습니다

추후에 반정규화로 게시물에 댓글 수에 대한 것을 처리한다면, 동일 Aggregate 로 볼 수 있지만, 현재는 생명 주기를 함께하는 형태는 아니라고 판단했기 때문에 분리해서 놔두었습니다

안그래도 erd 를 확인했을때 feed.comment_count 로 생명주기를 공유한다고 생각을 해서 저는 하나의 aggregate 로 생각을 했는데 아직까지는 분리되어있는 상태이군요!

추후 병합되는 aggregate 나 subdomain 이 있으면 참고하여 설계하겠습니다

[toothlessdev]

저도 3depth 유지해서 한다는 가정하에 aggregate 로 나눈다면
좀 더 강하게 결합되고 생명주기를 공유하는 개념으로 묶을 수 있을것 같다는 관점입니다

[toothlessdev]

@polyglot-k 님 의견은 이렇게 정리하면 깔끔할 것 같습니다

entities는 DB 스키마/순수 도메인 엔티티 단위로 최대한 얇게 유지하고
실제 사용자 액션 단위의 생명주기(생성/수정/삭제, optimistic update/rollback, 캐시 동기화 등)는 features가 유즈케이스 단위로 책임하는 방향입니다

즉 add-comment, delete-comment 같은 feature가 여러 entity(feed, comment 등)를 조합해서 상태를 변경하고, 화면/캐시 정합성까지 포함한 흐름을 관리하는 방식으로 이해했습니다

이 방향으로 entities를 DB 스키마 기준으로 진행하는방식으로 하겠습니다
@kimgho @eunwoo-levi