카테고리 없음

관심사 분리

황성안 2021. 7. 30. 09:00
728x90
반응형

관심사 분리

컴퓨터 프로그램을 구별된 부분으로 분리시키는 디자인 원칙, 지향점

이미 하고 있으며, 코드레벨로 사용하고 있다.

private fun baedal(){
    음식점 찾기()
    메뉴고르기()
    지불하기()
    배달기다리기()
}

코드레벨 관심사 분리

다른 함수가 무슨 일을 하는 지는 중요하지 않다.

내가 호출하는 코드만 알면 되며, 표현 계층은 사람이 읽을 수 있게.

스프링은 왜 이렇게 만들었을까?

굳이 레이어를 구분해서 만들었을까?

Servlet filter, Controller, Service, Repository

계층에 영향을 주지 않으며 영향을 끼치지 않는다. 호출하는 계층만 중요하다.

주니어도 쉽게 개발 가능하다. (잘 나누어져 있어서 가능)

코드 이상하다고 다른 계층에 전파되지 않는다.

문제 원인 파악이 쉽고, 엔터프라이즈(프레임워크) 코드 어떻게 동작하는지 개별 개발자가 관심사가 아니다.

대규모 프로젝트 개발 유리

개발자 관심 분리

  • 프론트 테스트가 아직....
  • 백엔드가 아직....

=> 교착 상태 (Deadlock)

  • Swagger를 잘 만들었으면

API 정의 후 제대로 동작을 하지 않는다면, 개발자 책임.

먼저 할 일은, 깡통이더라도 미리 API를 구성을 해주어야 한다. (그래야 서로가 편하다)

블랙박스식 개발

input > black box > output

  • 화이트 박스식, 코드 리뷰가 활성화되며, 코드 품질이 중요.

리팩토링이 유리하다. (테스트 코드)

*연관 개념 juit, mockito,

병목지점을 찾기 쉽고 기능 분리가 쉽다.

성능 개선

예시> 거대한 모듈을 용량을 줄이고 성능을 개선해서 같은 결과값이 나온다면 리팩토링 성공

어떤 모듈을 개선해야 하는가?

-> 실행 시간이 제일 긴 모듈

예시> 동접 30만의 배달 주문 서비스를 설계 해보시오

로드 밸런서 - 게이트 웨이 API 데이터베이스

                                   API        
                   게이트웨이     API     
로드벨런스                         API        
                   게이트웨이     API     DB 
로드밸런스                         API        
                   게이트웨이     API                      
                                   API
  • 관심사를 분리하고
  • MSA 설계를 해보자.

결론

  • 관심사를 분리를 해서 역할을 잘 나누고 개발하는 시스템 안정성을 올릴 수 있다.
  • 모듈화가 중요하다. (내가 책임을 최대한 벗어날 수 있는 방법;;;:wink:
  • 결국은 구조가 중요하다. (시스템에서도, 모듈에서도)서버 -> 클라우드 -> 도커 -> 쿠버네티스 -> 서비스메시 다시 찾아보기.

IT 기술 직무

  • 다양한 SW 직무가 있다.
  • 신입으로 가기 어려운 것도 많고 영업이나 기획으로 가는 비개발 영역이 있다.
728x90
반응형