DDD에서 큰 집계를 만드는 방법

안녕! 제 이름은 Antonio이고 꽤 오랫동안 DDD에 대해 읽어왔습니다. Domain Driven Design은 일부 엔터프라이즈 응용 프로그램에 적합한 도구라고 생각하므로 최근에 회사에서 사용하려고 시도했습니다.

계속 읽기 전에 DDD 및 관련 개념에 대해 잘 알고 있다고 가정합니다(소개를 포함하지 않은 점에 대해 죄송합니다. DDD에 대한 소개 기사가 이미 너무 많아서 다른 글을 쓰고 싶지는 않습니다.) .

문제

그렇다면 DDD에 어떤 문제가 있습니까? 대규모 집계 구현(설계가 아닌 구현에 중점). 내가 크다고 말할 때, 나는 그것들이 많은 다른 엔티티나 많은 종속성을 포함한다는 것을 의미하는 것이 아니라 동일한 엔티티의 많은 인스턴스를 포함한다는 것을 의미합니다. 예를 들어 은행 계좌 집계에는 거래라는 하나의 하위 엔터티가 있습니다. 이제 해당 은행 집계에는 해당 엔터티의 수백 또는 수천 인스턴스가 있을 수 있습니다.

내 회사 도메인이 Roads 및 Stops 정도라고 가정해 보겠습니다(예시일 뿐입니다). 둘 다 정체성이 있기 때문에 실체입니다. 이 경우 Road는 루트 집계이고 Stop는 해당 집계의 자식 엔터티입니다. 각각 2개 또는 3개의 필드가 있다고 가정해 보겠습니다. 실제로는 중요하지 않습니다. 다음은 Python에서 해당 모델을 빠르게 구현한 것입니다(데이터 클래스를 사용하지 않았으며 이 토론에서 중요하지 않기 때문에 많은 논리가 누락됨).

class Road:
    id: int
    name: str
    stops: [Stop]
    ...

class Stop:
    id: int
    latitude: int
    longitude: int
    ...

이제 스토리지에서 해당 엔티티를 검색하기 위해 리포지토리를 생성해야 합니다. 몇 가지 SQL 쿼리나 파일 읽기 또는 원하는 것을 선택하면 충분합니다. 이것이 우리의 리포지토리라고 가정해 보겠습니다(인터페이스, 종속성 주입 등은 이 경우와 관련이 없으므로 피합시다).

class RoadRepository:
     def get(id: int) -> Road:
         ...
     def save(road: Road) -> None:
         ...

충분히 쉽죠? 좋아, 우리 모델을 계속 구현하자. get 방법은 정말 쉽지만 save 방법에는 숨겨진 복잡성이 많이 있습니다. postgres와 같은 관계형 데이터베이스를 사용하여 엔터티를 저장한다고 가정해 보겠습니다. roads와 stops라는 두 개의 테이블이 있고 관계 등이 있다고 가정해 보겠습니다.
save 메서드를 구현하려면 모든 하위 엔터티를 업데이트해야 합니다. 그리고 그것이 문제입니다. Road 인스턴스에 345개의 서로 다른 정류장이 있는 경우 어떻게 됩니까? 어떻게 업데이트합니까? 이에 대한 최종 답변은 없지만 몇 가지 제안이 있습니다!

솔루션 1

이것은 무차별 대입으로 문제를 해결하는 것과 같습니다. 모든 것을 삭제하고 다시 생성하십시오.

소품

간편한 구현

단점

효율성이 확실하지 않습니다. 그러나 나는 그렇게 좋지 않다고 추정합니다.

데이터베이스 수준에서 고유 식별자를 설정하면 동일한 식별자를 유지하는 데 문제가 발생합니다.

솔루션 2

집계 수준에서 모든 변경 사항을 추적합니다. 이 같은:

class Road:
    id: int
    name: str
    stops: [Stop]

    def update_stop(self, stop: Stop):
        ... some logic to update the list ...
        self._changes.append({
           'type': 'UPDATE',
           'stop': stop,
        })

그런 다음 리포지토리에서 해당 변경 사항 목록을 읽고 개별적으로 적용합니다(또는 변경 유형에 따라 대량으로, 예를 들어 삭제, 생성 등을 함께 그룹화할 수 있음).

소품

평균적으로 필요한 db 작업이 더 적기 때문에 첫 번째 솔루션보다 더 효율적입니다.

단점

우리 도메인이 사업과 관련 없는 논리로 오염되었습니다.

변경 사항을 추적하려면 많은 코드가 필요합니다.

토론할 시간입니다!

이 문제에 대해 어떻게 생각하세요? 전에 직면한 적이 있습니까? 추가 솔루션이 있습니까? 댓글 달아주시면 상담해드리겠습니다 :)