관심사의 분리(SOC: Seperation Of Concern) 원칙

리팩토링때 참고하기 위해 간단하게 정리한 관심사 분리 원칙 개념

🗂 관심사의 분리?

: 한번에 한 가지 일만 처리할 수 있도록 나누는 것
➡️ 코드가 단위별로 하나의 관심사에 충실할 수 있도록 만드는 것

프론트엔드 특성상 유저 시나리오 변경에 따라 인터페이스나 로직 변경이 빈번함

• 관심사 분리 원칙 적용 ❌
  : 전체 기능을 파악하기 위해 읽어야 할 코드가 많고 길어서 파악이 어려움, 수정시 전체 코드를 변경하게 될 수 있음

• 관심사 분리 원칙 적용 ⭕️
  : 코드 파악을 위해 읽어야하는 코드 단위가 작음, 수정 시 해당 사항이 있는 일부분먼 수정하면 됨

➡️ 따라서 관심사 분리는 필수!

---

관심사 분리의 장점

1. 낮은 결합도(Loose Coupling)
: 각각의 코드가 서로 얽혀있지 않고 독립적으로 잘 분리됨
(결합도: 의존성의 정도를 나타내며 다른 모듈에 대해 얼마나 많은 지식을 갖고 있는지를 나타내는 척도, 결합도가 높을 수록 함께 변경해야하는 모듈의 수가 늘어남 )

2. 높은 응집도(High Cohesive)
: 유사한 내용끼리 비슷한 위치에 잘 모여 있음
(응집도: 내부 요소들이 연관되어 있는 정도, 하나의 목적을 위해 긴밀히 협력한다면 그 모듈은 높은 응집도를 가짐)

---

그래서 관심사 분리 이거 어떻게 하는건데?

가장 대표적인 예제
유저 인터페이스(View)와 비즈니스 로직(Business/Domain logic)으로 분리(어떤 수준까지 분리할지 각자 기준을 정하는 것이 중요)

유저 인터페이스(view)

• 사용자와 어플리케이션이 화면에서 상호작용하는 영역
  • 데이터 조작(사용자 - 행동)
• 데이터를 화면에 표시하는 영역
  • 데이터 시각화(데이터 - 화면)

예) img, form, button...

비즈니스 로직(business/domain logic)

• 현실 세계의 비즈니스 규칙
  • entity: 예약에는 사용자 정보, 펫 정보, 병원 정보가 필요
  • usecase: 병원 회원이라면 예약이 불가능하다
• 사용자가 view를 통해 전달한 UI event를 어떠한 데이터 변화를 하게 할지 전달하는 역할
• 전달받은 요청에 따라 적절히 데이터를 변화하는 역할

➡️ API 호출 로직을 view 로직과 분리하는 것만으로 어느 정도 관심사 분리를 달성할 수 있음

Headless UI
: 디자인 시스템에서 스타일을 담당하는 부분과 로직과 생태를 담당하는 부분을 분리하는 것

---

참조하면 좋을 링크 모음
실무에서 바로 쓰는 frontend clean code
주니어 개발자의 클린 아키텍처 맛보기
프론트엔드에서 비즈니스 로직과 뷰 로직 분리하기 (feat.MVI 아키텍쳐)