도메인 객체 생성 로직 관련 고민

글을 읽기 전

현재 우아한테크코스에서 진행하고있는 '런세권' 프로젝트에서 생성 로직을 어떻게 개선할지 고민하는 과정을 담은 글이다.

글을 읽기 전에 이해를 돕기위해 프로젝트에 대해 간략하게 소개하자면, 현재 런세권은 주변 러닝 코스를 쉽게 찾을 수 있도록 도와주는 안드로이드 앱이며 이러한 러닝 코스를 구성하는 도메인 객체는 다음과 같이 Course, Segment, GeoLine, Coordinate가 있다.

`Course`는 러닝 코스를 의미하고, `List<Segment>`를 가진다. 그리고 `Segment`는 경사도에 관련한 정보를 가진 객체들이고, 이들은 다시  `List<GeoLine>`을 갖는다. `GeoLine`은 지표면의 어느 한 선을 개념적으로 표현한 것이며, 2개의 `Coordinate`를 가진다.

 

생성 관련 책임을 어떻게 할까?

public Course(String name, RoadType roadType, List<Coordinate> rawCoordinates) {
    this.id = null;
    this.name = new CourseName(name);
    this.roadType = roadType;
    List<Coordinate> coordinates = CoordinateBuilder.fromRawCoordinates(rawCoordinates)
            .removeSimilar()
            .smooth()
            .build();
    List<GeoLine> geoLines = GeoLineBuilder.fromCoordinates(coordinates)
            .build();
    this.segments = SegmentBuilder.fromGeoLines(geoLines)
            .mergeSameElevationDirection()
            .mergeSameInclineType()
            .build();
    this.length = calculateLength(segments);
    this.inclineSummary = InclineSummary.of(segments);
    this.difficulty = Difficulty.fromLengthAndRoadType(length(), roadType);
}

Builder 패턴으로 작성하게 된 계기
처음에는 각 도메인 객체에 생성 관련 책임을 주고 이를 각자 생성하도록 했다. 근데, 생성 로직이 너무 복잡해진 만큼 그대로 두기에는 다른 중요한 도메인 로직들이 잘 보이지 않았다. 그래서 이러한 생성 로직을 좀 분리하고자 했고 그 대안으로 Builder 패턴을 활용했던 것이다.

하지만, 현재 생성 책임이 너무 혼재해 있는 것 같다는 생각이 듦.

그리고 Course에서는 사실 Segment의 존재만 알면 되는데 Coordinate, GeoLine의 존재도 알아야한다. 심지어 이들을 생성하는게 CoordinateBuilder, GeoLineBuilder임을 알고 있어야 한다. SegmentBuilder, CoordinateBiuilder의 경우에는 메서드의 호출 순서도 알고 있어야 한다.

Course 생성자에서 갖는 책임이 너무 거대한 것 같다.

 

Builder 패턴에 대한 생각
Builder 패턴의 목적 자체는 객체의 복잡한 생성 과정 및 많은 파라미터들을 매핑하는 과정들을 단순화 하기 위한 패턴임을 안다.

우리 도메인 로직상 객체 생성 방식이 복잡하다. ✅ 이건 인정

근데 Builder 패턴의 궁극적인 목표는 ‘선택적인’ 생성(유연한 조합)이 가능하도록 하는 것이다. 예시로 식사 일정표를 만든다고 하면 누군가는 점심 식사, 저녁 식사만 주입하여 생성하고 싶을 수 있고, 누군가는 아침, 점심, 저녁 식사 모두 넣어 생성하고 싶을 수 있다.

그런 관점에서 우리 도메인은 Builder 패턴의 ‘선택적인’ 생성이 필요한가? 이 부분은 ❌

항상 같은 순서와 형식으로 생성하고 있음. 그럼 Builder 패턴의 네이밍을 따라갈 필요가 있나?

기존 생성자 로직을 단순화 하고 이에 대한 생성 책임은 Factory, Creator 등.. (네이밍은 자유)로 넘겨 더 명확하게 하자!

 

그럼 Factory 패턴은 뭔데
Factory 패턴은 생성 책임을 추상화 하고자 만들어진 패턴이다. 근데 사실 GoF 정의에 의하면 여기서 해결하고자 하는 객체의 복잡한 생성 과정을 추상화 한다기보다 클라이언트 입장에서 여러 구현체들을 선택해야 하는 코드를 추상화 한 것 즉, 객체 생성의 책임을 추상화 한 것이다.


패턴에 너무 매몰되지 말자
결국 내가 하고 싶은건 생성자 로직 단순화 + 생성 책임 명확하게 분리

 

개선하게 된 것

public Course(String name, RoadType roadType, List<Coordinate> rawCoordinates) {
    this.id = null;
    this.name = new CourseName(name);
    this.roadType = roadType;
    List<Coordinate> coordinates = CoordinateBuilder.fromRawCoordinates(rawCoordinates)
            .removeSimilar()
            .smooth()
            .build();
    List<GeoLine> geoLines = GeoLineBuilder.fromCoordinates(coordinates)
            .build();
    this.segments = SegmentBuilder.fromGeoLines(geoLines)
            .mergeSameElevationDirection()
            .mergeSameInclineType()
            .build();
    this.length = calculateLength(segments);
    this.inclineSummary = InclineSummary.of(segments);
    this.difficulty = Difficulty.fromLengthAndRoadType(length(), roadType);
}

 

기존에는 Course가 segments를 만들기 위해서 coordinates도 만들고, geoLines도 만들고 있었음. 그리고 해당 객체들을 만들기 위해서 생성 순서까지 기억하고 있었다. 하지만, Course는 이러한 사실을 알고 있을 필요가 없다. 그러면 이러한 생성 로직들을 더 추상화 하는게 맞지 않을까?

 

public Course(String name, RoadType roadType, List<Coordinate> rawCoordinates) {
    this.id = null;
    this.name = new CourseName(name);
    this.roadType = roadType;
    **this.segments = SegmentFactory.create(rawCoordinates);**
    this.length = calculateLength(segments);
    this.inclineSummary = InclineSummary.of(segments);
    this.difficulty = Difficulty.fromLengthAndRoadType(length(), roadType);
}

public class SegmentFactory {

    public static List<Segment> create(List<Coordinate> rawCoordinates) {
        List<Segment> rawSegments = GeoLineFactory.create(rawCoordinates).stream()
                .map(GeoLine::toSegment)
                .toList();

        List<Segment> mergedSegments = mergeSameElevationDirection(rawSegments);

        return mergeSameInclineType(mergedSegments);
    }

    private static List<Segment> mergeSameElevationDirection(List<Segment> segments) {
        // ...
    }

    private static List<Segment> mergeSameInclineType(List<Segment> segments) {
        // ...
    }
}

public class GeoLineFactory {

    public static List<GeoLine> create(List<Coordinate> rawCoordinates) {
        List<Coordinate> coordinates = CoordinateFactory.create(rawCoordinates);

        // ...

        return lines;
    }
}

public class CoordinateFactory {

    public static List<Coordinate> create(List<Coordinate> rawCoordinates) {
        List<Coordinate> nonSimilarCoordinates = removeSimilar(rawCoordinates);
        List<Coordinate> coordinates = smooth(nonSimilarCoordinates);

        validateValidCoordinateSize(coordinates);
        return coordinates;
    }

    private static void validateValidCoordinateSize(List<Coordinate> rawCoordinates) {
        if (rawCoordinates.size() < 2) {
            throw INVALID_COORDINATE_COUNT.create(rawCoordinates.size());
        }
    }

    private static List<Coordinate> removeSimilar(List<Coordinate> rawCoordinates) {
        // ...
    }

    private static List<Coordinate> smooth(List<Coordinate> rawCoordinates) {
        // ...
    }
}

그래서 Builder 네이밍을 제거하고 Factory로 변경했으며 각 생성 로직들을 추상화 했다. 결과적으로 Course에서는 더 이상 Coordinate, GeoLine, Segment의 생성 방식을 궁금해 하지 않는다. 그리고 각 Factory 객체들이 Course → Segment → GeoLine → Coordinate로 만들어진 도메인 구조와 동일하기 때문에 이해하기가 쉬워졌다.

아쉬운 점은 Factory라는 네이밍인데, 이를 팀 내에서 합의한다면 해당 네이밍을 그대로 사용하고 아니라면 다른 네이밍을 고민해보는 것이 좋을 것 같다.

 

생성 로직에 대한 고민

 

현재 도메인은 `Course` → `Segment` → `GeoLine` → `Coordinate`의 구조로 만들어져있다.

`GeoLine`, `Coordinate`들은 `Course`와 성질이 다르다. 좌표는 부드러울 필요가 없고, 좌표들 간의 거리가 먼 것도 상관없다. 세그먼트들은 경향성이 같다고 합쳐질 필요도 없다. ‘코스’라는 범위 안에서 이해할 때 의미를 갖는 것은 맞다. 게다가 코스를 구성하는 좌표들만이 부드러워야 하고, 거리가 짧아야 하고, 경향성은 합쳐져야 한다. 맞는 말이다.

하지만, 조금 의아한 점은 `GeoLine`, `Coordinate` 는 모두 ‘코스’라는 범위 내에서 만들어진 객체들이다. 그렇다면 팀원들 간에 그러한 점을 공유하고 있는 상황에서 생성 시 좌표들이 부드러워지고, 거리가 먼 것을 보정하는 로직을 `GeoLine`, `Coordinate` 쪽으로 옮겨도 문제없지 않을까? 오히려 `Course` 에 너무 많은 로직들을 담고 있는건 아닐까? `Course`에서만 의미를 가진다곤 하지만, 이 도메인을 만들때 `Segment`, `GeoLine`, `Coordinate`는 모두 같은 맥락에서 나온 객체들이다.

이렇게 생각하면 하나의 갈림길이 나오는 것 같다.

 

- `Course` 외의 하위 객체들을 순수하게 ‘지리적 선’, ‘지리적 점’의 역할로 볼 것인가?

만약 순수한 지리적 선, 점의 역할로 본다면 생성 로직들은 `Course`에 분리되는 것이 맞다. 하지만, 그런게 아니라 `GeoLine`, `Coordinate`, `Segment`도 어느정도 도메인 로직을 포함할 수 있는 존재들로 본다면 생성 로직을 각자가 부담하는 것이 맞는 것 같다.

이런 맥락을 고려했을 때 나는 보통 하나의 기준으로 결정하는 것 같다. 바로 `재사용성`이다. 다른 프로젝트에 재사용하는 경우는 건너뛰고, 현재 프로젝트에서 `Course`가 아닌 객체들을 재사용하는 일이 있나? 혹은 있을까? 지금 당장이라면 프로젝트에서는 없다. `Course` 외에 하위 객체들은 사용되는 일이 없다.

그렇다면, 추후에 재사용될 일이 있을까? 꽤 있을 것이다. 예를 하나 들면 현재는 `Course` 단위로 러닝 코스를 인식하고 있지만 나중에 `Segment` 단위로 러닝 코스를 인식하고 각 `Segment`마다의 사용자별 기록을 기록하는 경우가 있을 것 같다. 실제로 Strava에서는 해당 방식으로 러닝 코스를 인식하고 있다. 하지만 각 객체를 생성할 때 경향성을 합치고, 좌표를 보정하는 이런 로직들은 모두 어플리케이션에서 필요하기 때문에 만들어진 로직들이다. 그래서 `Segment` 단위로 러닝코스를 인식해도 여전히 사용될 가능성이 높은 로직들이다.

그럼 결국 각 도메인 객체들이 각자 생성 로직을 갖고 있는게 맞나? 사실 그건 아니라고 생각한다. 나도 ‘코스’라는 범위 내에서 의미를 갖게되는 로직이라는 팀원의 의견에 동의하는 바이다. 그래서 좀 더 코드적으로 문제를 바라볼 필요가 있을 것 같다.

 

public Course(String name, RoadType roadType, List<Coordinate> rawCoordinates) {
    // ...
    List<Coordinate> coordinates = CoordinateBuilder.fromRawCoordinates(rawCoordinates)
            .removeSimilar()
            .smooth()
            .build();
    List<GeoLine> geoLines = GeoLineBuilder.fromCoordinates(coordinates)
            .build();
    this.segments = SegmentBuilder.fromGeoLines(geoLines)
            .mergeSameElevationDirection()
            .mergeSameInclineType()
            .build();
    // ...
}

현재 문제가 되는 지점이다. 좀 더 명확하게 문제를 정의하자면 ‘생성 책임 중 생성 방식을 Course에 둘 것이냐 아니면 추상화 할 것이냐’이다. 코드를 보며 상당히 많은 고민을 해봤는데, 결론은 Course에 두는 것이 좋다. 이렇게 생각하게 된 가장 큰 이유는 코드의 파편화 때문이다.

새로운 신입 개발자가 왔다고 가정하자. 코스를 어떻게 생성하는지 궁금해서 생성자를 봤는데, 각 좌표들을 SegmentFactory에서 처리하고 있는 것을 봤다. 그래서 해당 팩토리에 들어갔더니 또 GeoLineFactory를 호출하고 있다. 그러면 또 한번 더 들어가는식으로 코스가 생성되는 과정을 쫓아가야 한다. 이 과정에서 만약 컨텍스트를 놓친다면 이를 다시 확인하는데 어려움을 겪을 것이다. 하지만 지금의 구조는 충분히 그 컨텍스트를 잊지않고 유지하며 코드를 읽을 수 있다. 코스가 좌표를 Segment로 만드는 과정이 한 눈에 보이니 말이다. 즉, 유지보수하기가 편해진다.

두 번째로는 정보 전문가의 관점이다. Course는 Segment, GeoLine, Coordinate가 생성되기 위해 필요한 정보를 모두 가지고 있다. 즉, Course는 각 하위 객체들의 정보 전문가이다. 그래서 각 하위 객체들의 생성 책임을 갖는 것이 흐름상 자연스럽다.

그래서 생각을 바꿨다. 하지만 여전히 생성자가 비대한 것은 맞다고 생각한다. 예를 들어 생성자가 궁금해서 들어왔는데, 아직은 궁금하지 않은 좌표 처리 과정을 봐야한다면 조금 피곤할 것이다. 그래서 다음과 같이 개선할 수 있을 것 같다.

 

// 1번
public Course(String name, RoadType roadType, List<Coordinate> rawCoordinates) {
    this.id = null;
    this.name = new CourseName(name);
    this.roadType = roadType;
    this.segments = refineCoordinates(rawCoordinates);
    this.length = calculateLength(segments);
    this.inclineSummary = InclineSummary.of(segments);
    this.difficulty = Difficulty.fromLengthAndRoadType(length(), roadType);
}

private List<Segment> refineCoordinates(List<Coordinate> rawCoordinates) {
    List<Coordinate> coordinates = CoordinateBuilder.fromRawCoordinates(rawCoordinates)
            .removeSimilar()
            .smooth()
            .build();
    List<GeoLine> geoLines = GeoLineBuilder.fromCoordinates(coordinates)
            .build();
    reutrn SegmentBuilder.fromGeoLines(geoLines)
            .mergeSameElevationDirection()
            .mergeSameInclineType()
            .build();
}
```

```java
// 2번
public static create(String name, RoadType roadType, List<Coordinate> rawCoordinates) {
    List<Coordinate> coordinates = CoordinateBuilder.fromRawCoordinates(rawCoordinates)
            .removeSimilar()
            .smooth()
            .build();
    List<GeoLine> geoLines = GeoLineBuilder.fromCoordinates(coordinates)
            .build();
    List<Segment> segments = SegmentBuilder.fromGeoLines(geoLines)
            .mergeSameElevationDirection()
            .mergeSameInclineType()
            .build();

    return new Course(name, roadType, segments);
}

private Course(String name, RoadType roadType, List<Segment> segments) {
    this.id = null;
    this.name = new CourseName(name);
    this.roadType = roadType;
    this.segments = segments;
    this.length = calculateLength(segments);
    this.inclineSummary = InclineSummary.of(segments);
    this.difficulty = Difficulty.fromLengthAndRoadType(length(), roadType);
}

특히 1번 코드가 현재 기준으로 최선이라고 생각한다. 팀에서 객체를 생성하는 방식이 모두 생성자를 통해 생성하고 있기 때문이다. 그리고 이렇게 메서드로 분리하는 것이 생성자 속에서 맥락의 변화를 주기도 하고, 어떤 방식으로 Segment가 생성되는지 궁금하다면 `refineCoordinates`만 확인하면 되기 때문이다.

 

 

결론

이번 기회에 프로젝트 도메인에 대해서 다시 한번 깊게 고민하는 계기가 되었다.

 

기존에는 Course에서 의미를 갖더라도 같은 맥락에서 나온 도메인 객체라면 해당 맥락을 가진채 각자의 책임을 가지는 것이 더 좋은 방향이라고 생각했었다. 하지만, 자칫 과도하게 책임을 나누게 되면 오히려 유지보수 하기 힘든 코드가 될 수 있다는 것을 알게되었다. 뭔가 좀 추상적인 거 같다.

 

그래서 다시 한번 위의 예제로 정리하면 Course에서 Segment, Coordinate의 변경을 한다는 점이 내겐 불편함으로 다가왔었다. 그래서 Segment, Coordinate, GeoLine 이들이 서로 Course에서 이뤄지는 책임을 갖는 것이 더 좋은 방향이라고 생각했다. 하지만 팀원의 말처럼 현재 Course에서만 Segment, …의 보정이 필요하다. 즉, 이건 Course의 도메인 로직이다. 그래서 다음과 같이 리팩토링을 진행했다.

 

public Course(String name, RoadType roadType, List<Coordinate> rawCoordinates) {
    this.id = null;
    this.name = new CourseName(name);
    this.roadType = roadType;
    this.segments = refineCoordinates(rawCoordinates);
    this.length = calculateLength(segments);
    this.inclineSummary = InclineSummary.of(segments);
    this.difficulty = Difficulty.fromLengthAndRoadType(length(), roadType);
}

private List<Segment> refineCoordinates(List<Coordinate> rawCoordinates) {
    List<Coordinate> coordinates = CoordinateBuilder.fromRawCoordinates(rawCoordinates)
            .removeSimilar()
            .smooth()
            .build();
    List<GeoLine> geoLines = GeoLineBuilder.fromCoordinates(coordinates)
            .build();
    reutrn SegmentBuilder.fromGeoLines(geoLines)
            .mergeSameElevationDirection()
            .mergeSameInclineType()
            .build();
}

 

Builder를 사용하기 전 프로젝트 초기에 Segment, Coordinate, GeoLine들이 각자 이러한 책임을 갖고 있던 상태였기에 더 혼란스러웠던 것 같다. 팀원들간에 좋은 토론을 진행했던 것 같아 좋다. 그리고, 항상 정답은 없다는 점을 또 깨닫는다.