Clean Architecture - 항해 플러스 회고 (2주차)

 

들어가며

 

이번 2주 차 항해도 무사히 마쳤다. 이번 과제에서는 아키텍처 구조 설계에 대한 내용을 중점적으로 공부하였다.

그동안 주로 3-tier 아키텍처를 주로 사용해 왔었는데, 이번에는클린 아키텍처와 레이어드 아키텍처의 특징, 장단점 분석을 통해 객체지향적 관심사 분리에 대해 깊이 고민해 볼 수 있는 시간이었다.

 

 

 

 

 

클린 아키텍처 & 레이어드 아키텍처

 

클린 아키텍처

클린 아키텍처 [출처] https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

 

클린 아키텍처는 관심사의 분리를 명확히 하고, 비즈니스 로직을 외부 의존성으로부터 완전히 분리하는 것을 목표로 한다. 이를 통해 시스템의 유지보수성을 높이고, 외부 변화에 대한 영향을 최소화한다. 

 

1. 엔티티 (Entities)
엔티티는 시스템의 전사적 비즈니스 규칙을 캡슐화한 객체로, 외부로부터의 변화에 의존하지 않는다. 이는 가장 핵심적인 도메인 모델로, 애플리케이션 내에서 어떤 의존성에도 영향을 받지 않아야 한다.

 

2. 유즈 케이스 (Use Cases)
유즈 케이스는 애플리케이션의 비즈니스 규칙을 구현한 레이어로, 특정 도메인 동작을 수행한다. 유즈 케이스는 엔티티의 데이터 흐름을 조정하며, 비즈니스 로직을 외부 입출력이나 프레젠테이션 계층과 분리한다.

 

3. 인터페이스 어댑터 (Interface Adapters)
이 레이어는 유즈 케이스와 외부 시스템(데이터베이스, UI, API 등) 사이에서 데이터를 변환하는 역할을 한다. 예를 들어, DTO(Data Transfer Object)를 사용해 엔티티에서 외부로 전달할 데이터 구조로 변환하거나, 반대로 외부 데이터를 엔티티로 변환하는 작업을 담당한다. 이로 인해, 비즈니스 로직이 외부의 변화로부터 보호된다.

 

4. 프레임워크 & 드라이버 (Frameworks & Drivers)
이 레이어는 외부 시스템(웹 프레임워크, 데이터베이스, 메시징 시스템 등)과 상호작용하는 코드가 위치한다. 애플리케이션이 플랫폼, 라이브러리, 외부 API에 의존하지 않고, 비즈니스 로직은 이 레이어와 분리되어 독립적으로 동작할 수 있게 한다.

 

 

 

레이어드 아키텍처

 

레이어드 아키텍처 [출처] https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch01.html

 

레이어드 아키텍처는 시스템을 계층별로 분리하여 각 계층이 자신의 역할에만 집중할 수 있도록 설계한다. 일반적으로 프레젠테이션, 비즈니스 로직, 데이터 접근 계층으로 구성되며, 각 계층은 상위 계층에서 하위 계층으로 의존성이 흐른다.

 

 

 

 

목표

이번 과제의 주제는 수강 신청 API 작성이었다. 기술적으로는 동시성 처리와 아키텍처 설계를 고려하여 개발하는 것이 핵심이었다. 특히, 다중 서버 환경에서 동작을 고려해야 했기 때문에, 애플리케이션 레벨의 락 대신 DB 레벨에서의 락을 설정하는 것이 필요했다. 또한, 아키텍처는 클린 아키텍처와 레이어드 아키텍처의 중간 지점인 클린 레이어드 아키텍처를 기반으로 설계했다.

 

 

 

 

 

새로 알게 된 것

1. Repository 인터페이스의 의존성 분리

지금까지는 Repository 인터페이스를 항상 외부 의존성에 두었기 때문에, 외부 변화가 생기면 도메인 계층에도 영향을 미쳤다. 하지만, 도메인이 필요로 하는 메서드만 도메인 계층에서 인터페이스로 정의하고, Infrastructure 계층에서 이에 대한 구현체를 만듦으로써 도메인이 외부 변화에 영향을 받지 않도록 설계할 수 있었다.

 

2. Application 계층

이번 과제에서 Controller와 Service 간에 Application 계층을 새롭게 추가했다. 이 계층에 Facade 패턴을 적용하여 여러 서비스 로직을 단순화된 인터페이스로 제공하고, 복잡한 비즈니스 로직을 하나로 묶어 처리할 수 있게 했다.

 

3. 낙관적 락 & 비관적 락

낙관적 락 (Optimistic Lock)

- 낙관적 락은 기본적으로 데이터에 락을 걸지 않고, 트랜잭션이 완료될 때까지 다른 트랜잭션이 해당 데이터를 수정하지 않을 것이라고 가정한다.

- version을 이용하여 읽을 때와 쓸 때의 정합성을 확인하고 맞다면 업데이트를 수행한다.

- 만약 version이 맞지 않다면 예외가 발생하여 트랜잭션이 실패하게 된다.

 

비관적 락 (Pessimistic Lock)

- 비관적 락은 데이터에 대한 접근이 이루어질 때 항상 락을 걸고, 다른 트랜잭션이 해당 데이터를 접근하지 못하도록 막는다.

- 다른 사용자는 먼저 접근한 사용자가 변경 사항을 커밋하고 레코드 잠금을 해제할 때까지 기다려야 한다.

 

 

이번 과제에서는 비관적 락을 선택했다. 이유는 낙관적 락이 선착순에 대한 보장을 제공하지 못하기 때문이다. 낙관적 락은 레코드 락을 걸지 않음으로써 오버헤드를 줄일 수 있는 장점이 있으나, 업데이트 시 버전이 맞지 않으면 트랜잭션이 실패하고 다시 시도해야 하며, 이로 인해 순차적인 보장이 어려워진다. 반면, 비관적 락은 대기열에서 순차 보장을 제공하므로, 여러 사용자가 동시에 요청할 경우에도 데이터의 일관성을 유지할 수 있다.

 

 

 

 

 

앞으로 개선해야 할 것

1. 코틀린 스프링에서 JPA 엔티티에 대한 정의

JPA 엔티티를 정의할 때 코틀린에서는 var와 val을 사용하여 필드를 선언하게 된다. 하지만 여기서 중요한 설계 고민이 필요하다.

var로 필드를 정의할 경우 필드 값이 변경 가능해져, 무분별한 변경을 허용할 수 있다. 이는 특히 도메인 모델에서는 치명적일 수 있는데, 비즈니스 로직 상에서 객체의 불변성이 중요한 경우 예기치 못한 오류를 초래할 수 있다.
반면, val로 정의할 경우 필드가 불변이 되어 객체의 상태 변경을 방지할 수 있다. 하지만 JPA에서는 엔티티를 영속화할 때 필드 값을 변경해야 하는 경우가 발생할 수 있는데, 이때는 문제가 될 수 있다. 예를 들어, 업데이트 시 불변 필드를 변경하지 못해 영속성 컨텍스트와의 동기화가 어려워진다.

Java에서는 보통 private 필드와 getter, setter 메서드로 필드를 보호하고, 접근을 제한하는 방식이 일반적이었다. 하지만 코틀린에서는 getter와 setter를 자동으로 제공하기 때문에, 이를 대신해 val로 불변성을 확보하거나, 필요한 경우에만 var를 사용해 특정 상황에서만 값을 변경할 수 있도록 해야 한다.

이런 설계 관점에서 JPA 엔티티는 변경 가능한 필드와 불변 필드를 명확하게 분리하고, 도메인 로직의 안정성을 고려해 설계해야 한다. 불필요한 변경을 방지하려면, 중요한 비즈니스 로직이 담긴 필드는 가급적 val로 선언하고, 필요한 경우에만 var로 변경 가능성을 열어두는 것이 바람직하다.

 

 

 

 

 

마치며

이번 2주 차 과제에서도 1주 차 때와 같이 정말 많은 부분을 고민해 보고, 뜯어고쳐보고 그랬던 것 같다. 그 과정에서 몰랐던 것을 깨닫고, 갇혀 있었던 생각을 좀 더 깨울 수 있는 시간이 되었다.

이제 3주 차부터는 하나의 주제로 마지막 10주 차까지 디벨롭하는 과제로 알고 있다. 이번 1,2주는 이 과제를 위한 준비 과정이었다 생각하고 남은 과제도 열심히 진행할 예정이다.