5주차 - 영역과 로직

💡 클린 아키텍처는 로직, 목적 등.. 관심사를 분리하는 것.

• 관심사에 따라 계층을 나눔.
• 세부 구현을 염두한 설계가 아닌 도메인 중심으로 설계
• 내부에 있는 영역이 UI, DB, 인프라 등의 외부적인 것에 의존하지 않도록 설계

💡로직에는 크게 아래와 같이 나뉜다.

• UI 로직
• 응용(어플리케이션) 로직
• 도메인 로직 (비지니스 업무) 로직
• 인프라(연동) 성 코드 로직

위 4가지의 로직을 바탕으로 각각의 영역으로 나눌 수 있다.

💡크게 영역은 아래와 같다.

• UI 로직
  • 필수값 검증 ( 프론트단에서 validation 체크 )
  • 보이거나 / 안보이거나 ( display , display-none 등.. )
  • 팝업을 띄우거나 / 안띄우거나
  등등 의 UI 성 로직
  
  
  
• 응용 로직
  • 고객이 존재하는지 / 안하는지
  • 돈을 지불 했는지 / 안했는지
  • 어떠한 값이 있는지 / 없는지
    
    
• 도메인 로직
  • 실제 비지니스 업무로직
  • 계산을 한다거나, 실제 업무를 담당하는 로직
    
    
• 인프라 (연동) 로직
  • DB 연동
  • 외부 API 연동
  등등 로직 구현을 위환 환경 구성 로직

💡각각의 로직은 서로 섞이지 않고 각각의 위치에 들어가게 코드를 작성하여야 한다.

💡UI → 응용(APP) → 도메인 형태로 의존하여야 한다.

이말이 무엇이냐면, UI에서 받은 request를 도메인로직까지 가져와서 쓰면 안된다는 이야기다.

도메인 모델에서는 해결하려는 문제 영역을 표현하는 곳으로, 도메인 로직(비지니스로직)이 위치해야 되며 업무를 표현하는 데이터와 기능이 위치해 있어야 한다는 이야기이다.

 

 

❓ 개인적인 생각...

여기서 궁금한게.. UI 에서 받은 request를 실제 도메인로직에까지 사용하지 말라는데...

• 만약 UI에서 받은 request와 도메인로직에서 쓰이는 모델의 변수가 같을 경우에는 그냥 써도 되지 않을까? 하는 생각
• 위처럼 하지 않고 각각 쓰이는 로직에 모델에 알맞게 처리해야된다면, 일단 UI에서 request 받은 모델을 도메인로직에 쓰이는 모델에 결국 생성자나, setter로 set을 해주게 되는데... 모델에 set하는건 좋지 않다고 하였는데..

위 2가지 경우를 고려해서 생각하여 봤을때...

일단 request는 단순히 UI(사용자)에서 받은 값이므로 그안에 메서드(기능)을 넣는다면 도메인 로직에서 해야할 업무를 UI로직에서 부터 끌고 오는 것이라 생각된다.

즉, 그건 각각의 영역에 맞지 않는 행동을 하는 것이라고 본다.

때문에 각각의 모델을 만드는게 맞다고 생각된다.

실제 도메인 로직에 데이터+기능으로 이루워진 모델에 request를 다시 set하는게 맞다고 본다.

 

💡응용(APP) 로직에서 인프라 로직에 있는 알림톡 발송기능을 사용한다면?

위 같은 상황은 응용로직이 인프라로직을 직접적으로 의존하고 있는 모습이다.

이는 DIP를 위반한 것이다.

이는 4주차때 배운 interface를 만들고 그를 사용하는 형태로 바꾸면 된다.

위처럼 바뀌면 DIP를 위반하지 않고 구현이 가능하게 된다.

※ 클래스 다이어그램식으로 표현한것 아님.