Spring 1.2.1 관심사의 분리

분리(Separation)

서로 다른 기능 또는 관심사를 독립적으로 관리하여, 하나의 변경이 다른 부분에 영향을 최소화하도록 하는 설계 기법입니다.

1.2.1 관심사의 분리 (Separation of Concerns)

소프트웨어 개발에서 요구사항은 끊임없이 변화합니다. 비즈니스 프로세스의 변화뿐만 아니라, 애플리케이션이 기반으로 하는 기술, 운영 환경 등도 지속적으로 발전합니다. 따라서 개발자는 이러한 변화를 효과적으로 대처할 수 있도록 설계 초기부터 유연성을 고려해야 합니다.

객체지향 프로그래밍(OOP)은 초기 개발 시 약간의 번거로움이 있을 수 있으나, 변화가 발생했을 때 수정 범위를 최소화하고, 테스트 및 검증 시간을 줄여주는 큰 장점을 제공합니다.

관심사를 분리가 반드시 필요한가

애플리케이션이 매우 단순하고, 변경될 가능성이 거의 없는 경우라면 관심사를 과도하게 분리하는 것이 오히려 코드 구조를 복잡하게 만들고, 개발 시간과 리소스를 불필요하게 소모할 수 있습니다.

1. 애플리케이션의 단순성

2. 짧은 수명의 프로젝트

   프로토 타입, 일회성 작업 단기간에 사용되고 폐기될 예정이라면, 완벽한 계층 분리나 모듈화를 위한 과도한 설계가 오버 엔지니어링이 될 수 있습니다.

3. 명확한 변경 요구사항이 없는 경우

   변경 가능성이 극도로 낮은 시스템: 시스템이 매우 안정적이고, 향후 확장이나 변경의 가능성이 거의 없다면 단순한 구조가 더 효율적일 수 있습니다.

그래도 관심사를 분리하는 것이 좋은 이유

1. 미래의 불확실성

   현재 변경이 없다고 하더라도, 미래에는 요구사항이나 기술 환경이 바뀔 수 있습니다.

   초기에 관심사를 분리해두면 변화에 유연하게 대처할 수 있습니다.

2. 가독성과 유지보수성

   관심사가 명확하게 분리된 코드는 코드를 읽는 개발자에게 의도를 쉽게 전달하고, 유지보수를 더 효율적으로 할 수 있도록 도와줍니다.

3. 테스트와 디버깅의 용이성

   각각의 모듈이 독립적인 책임을 가지게 되면, 단위 테스트를 실시하기도 용이해지며, 문제가 발생했을 때에도 원인 파악이 쉽습니다.

4. 재사용성

   잘 분리된 모듈은 다른 프로젝트나 기능에 재사용하기 쉽습니다.

   이렇게 하면 중복 코드를 줄이고, 전체 코드베이스의 일관성을 유지할 수 있습니다

결론

관심사를 분리하는 것은 필수는 아닌 경우가 있습니다

• 작은 규모의 애플리케이션
• 변경 가능성의 거의 없는 경우

그러나 대부분의 경우, 특히 미래의 변경 가능성이나 유지보수, 확장성을 고려한다면 관심사를 분리하는 것이 장기적으로 더 큰 이점을 제공합니다.

관심사 분리 기준은 뭘까

요구사항으로 변경되야하는 영역에 따라 관심사를 나누는 방식이 좋다고 생각합니다.

이유는 클라이언트에게 필요한 정보를 전달하는 관심사는 클라이언트의 요청사항에 따라 변경되고

컨트롤러는 서비스를 이용하기 위해서 필요한 데이터를 전달할 때 모든 값이 있어야 하는지, 서비스가 원하는 양식이 있는지 상황에 따라 고려해야합니다.

서비스 계층도 외부 네트워크를 사용하거나 비즈니스 로직 내에서도 관심사가 다른 경우가 있습니다 그런 경우를 대비해서 관심사를 나누는 방법이 있습니다

카드 결제 비즈니스 로직

우리 회사는 미납 금액과 납입 금액 테이블이 나누어져있습니다.

미납이 있는 회원은 카드결제시 먼저 미납금액이 결제됩니다.

미납 금액을 납부하는 프로세스와 납입 금액 테이블 프로세스가 별개로 존재합니다.

그러니 미납에 대한 프로세스가 변경될때 서로 영향이 없도록 하는 것이 좋습니다.

코드를 한 곳에 모아놓으니 문제가 발생했습니다.

생각 정리

관심사를 분리하는 이유는 고객의 요구사항에 따라 코드를 변경해야하고 구현 기술의 변경, 외부 네트워크 솔루션의 변경등 하나의 서비스 기능은 내부에 여러 상황에 따라 수정하게 됩니다.

그런데 이 코드가 하나의 메서드 내부에 있다면 단순히 메서드 추출로 분리할 수 있지만 기술이 변경되거나 다른 솔루션을 사용한다면 문제는 그 관련된 기술을 사용하는 모든 메서드는 변경해야합니다.

코드 변경으로 인해 발생하는 해당 코드를 사용하는 오브젝트도 동작하는지 확인하는 테스트가 덩달아 필요하게 됩니다.

요구사항이 추가되고 변경될 때마다 관련된 오브젝트 코드도 테스트를 매번 반복해야합니다.

그러면 개발 속도도 늦어지며 확장하기 어려운 코드로 유지보수에 필요한 리소르가 많아지게 됩니다.

관심사를 분리하는 이유는

클라이언트의 요구사항으로 변경되는 구현코드만 테스트를 하기 위해서입니다.

클라이언트의 요구사항에 따라 관심사를 분리하고 서로 영향이 없도록 설계를 하게 되빈다.

그리고 설계 이후 클라이언트가 다른 기능으로 확장을 원하는 경우에는 다시 코드를 수정해야해야합니다.

객체지향 프로그래밍은 초기 설계는 복잡하지만 기능 확장이나 유지보수에는 절차적 프로그래밍보다 자유롭게 할 수 있습니다.

고려사항

• SRP(단일 책임원칙), OOP(개방 폐쇄 원칙)등 SOLID 원칙 언급으로 마무리 해야합니다.

  관심사의 분리는 일반적으로 단일 책임 원칙과 밀접한 관계가 있기때문입니다.

스프링은 관심사 분리 지원을 어떻게 하나

스프링은 횡단 관심사를 별도 코드로 분리할 수 있도록 지원하는 방법과

스프링이 유효성 코드 검사도 분리, 예최 처리 코드도 분리할 수 있습니다

트레이드 오프

과도한 분리 vs 유지보수성

• 기능이 단순한데도 불필요하게 계층과 모듈을 지나지게 세분화한다면, 오히려 유지 비용이 클 수 있다.
• 반면, 중장기적인 프로젝트에서 지나치게 단순한 구조로 시작하면 향후 변경시 대규모 리팩토링이 필요하다

단순한 파일럿 프로그램, 동작 유무 테스트 정도는 관심사를 분리하지 않는 것을 고려해볼만하다고 생각합니다.

다만 프로젝트가 작더라도 요구사항이 변경된다면 관심사를 분리하는 것이 유지보수와 테스트를 작성하기에 편하다고 생각합니다.

조기 최적화 경계

요구사항이 충분히 명확해진 뒤, 영역을 분리하는 것도 선택입니다.

처음부터 분리하고 코드를 작성하는 것보다 코드를 다 작성해보고 관심사가 같은 것끼리 분리하는 것도 좋은 방법이라고 생각합니다.

너무 이른 시점에 추상화를 하면 한번도 안쓰는 인터페이스가 나올 수 있습니다.

운영 환경 고려

관심사 분리가 코드 레벨뿐아니라, 배포 환경, 운영 모듈에 따라 적용될 수 있습니다.

공통 로깅,트랜잭셔 관리를 AOP 로 분리

로깅이나 트랜젹선과 같은 경우는 특정 계층에서 공통으로 사용하는 기술을 말합니다.

AOP로 구현하여 적용하면 공통 로직이 서비스 계층에 제외되어 순전한 비즈니스 로직을 수정하고나 배포할 수 있습니다.

강화 키워드: DDD(애그리게잇·도메인 이벤트), SOLID(SRP), AOP, Validation, ControllerAdvice, 트랜잭션 분리, 테스트 전략