용어
- 단위 테스트 (unit test)
- 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 절차
- 모든 함수와 메소드에 대한 테스트 케이스(Test case)를 작성하는 절차
- 테스트 케이스 (Test Case)
- 특정한 프로그램 경로를 실행 or 특정 요구사항에 준수하는 지를 확인하기 위해 개발된 입력 값, 실행 조건, 그리고 예상된 결과의 집합
객체 지향의 원칙 (SOLID)
- SRP (Single Responsibility Principle, 단일 책임의 원칙)
- 하나의 객체는 하나의 책임을 가져야 한다.
- OCP (Open-Closed Principle, 개방-폐쇄 원칙)
- 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
- 기존 코드 영향을 주지않고 새로운 기능or구성요소 추가 가능해야 한다.
- LSP (Liskov substitution principle, 리스코프 치환 원칙)
- 객체는 프로그램의 동작에 영향을 주지 않으면서 하위 객체로 바꿀 수 있어야 한다.
- 부모 클래스와 자식 클래스의 객체를 바꿔도 정상작동 해야함.
- ISP (Interface Segregation principle, 인터페이스 분리 원칙)
- 인터페이스는 구체적으로 유지 해야한다.
- 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
- 차의 행동(하나의 범용 인터페이스)
- 가속 하는 행동(역할 인터페이스)
- 감속 하는 행동(역할 인터페이스)
- 정지 하는 행동(역할 인터페이스)
- DIP (Dependency Inversion Principle, 의존성 역전 원칙)
- 프로그래머는 구체화가 아닌 추상화에 의존해야 한다.
- 상위 모듈은 하위 모듈에 의존 하면 X => 추상화에 의존해야 함
아키텍처 패턴
소프트웨어의 구조를 구성하기 위한 토대
모델뷰제어기 (MVC) 아키텍처 패턴
- UI가 필요한 어플리케이션에 많이 사용. (웹기반)
- MODEL : 기능과 데이터 보관
- VIEW : UI 담당
- CONTROLLER : 사용자로 부터 받은 요청을 입력과 처리. 모델과 뷰 사이에서 전달자 역할 담당
계층형 아키텍처 패턴
- 기능을 여러 계층으로 분할.
- 일반적으로 서비스, 저장소, 컨트롤러 계층으로 분리
- 서로 마주 보는 두 개의 계층 사이에서만 상호 작용
클린 아키텍처 패턴
- 내부 도메인으로 향하는 의존성을 가지는 여러 계층으로 분리하는 패턴
- 유지성과 확장성 유리
마이크로 아키텍처 패턴
- 작고 독립적으로 배포 가능한 서비스로 분할하는 패턴
- 하나의 시스템에서 여러 언어와 프레임워크 사용 가능
계층형 아키텍처 패턴
- 각 계층을 명확하게 분리, 자신의 바로 아래 계층에만 의존하게 해야 함.
계층화의 핵심
- 각 계층이 높은 응집도.
- 다른 계층과 결합도 최소화.
- 하위 계층이 상위 계층 의존X 독립적 동작
장점
- 관심사 분리고 구현 하고자하는 코드 명확하게 인지
- 독립적이고 의존성이 낮아 모듈 교체 시 수정이 용이
- 테스트 코드 용이
3계층 아키텍처
1. 컨트롤러(Controller) : 요청을 처리하고 응답하는 역할.
-
클라이언트의 요청 받기
-
요청에 대한 처리 서비스에 위임
-
클라이언트에게 응답 반환
-
Presentation Layer 계층
- 하위 계층에서 발생하는 예외를 처리
- 유효성 검사
- 요청 처리 후 반환.
2. 서비스 (Servese)
- 핵심적인 비즈니스 로직을 수행
- 요구사항 구현하는 계층
- Bsiness Layer
- DB정보 필요에 따라 repository에 요청
- 서로 다른 두 계층이 직접 통신하지 않게 다리 역할
- 장점
- 비즈니스 로직이 API 뒤에 숨겨져 있음 => 코드를 자유롭게 수정
- 저장소 패턴 및 가짜 저장소와 조합하면 높은수준의 테스트 작성 가능
- 단점
- 다른 추상화 계층 => 잘못 사용하면 코드의 복잡성 UP
- 한 서비스 계층이 다른 서비스 계층에 의존하는 경우, 의존성 관리가 복잡
- 서비스 계층에 너무 많은 기능을 넣으면 빈약한 도메인 모델과 같은 안티 패턴 발생
3. 저장소 (Repository)
- Peristence Layer = Data Access Layer
- DB 관리
- DB의 CRUD 처리
- 데이터 접근과 관련된 세부 사항 숨기는 동시에 데이터가 존재하는 거처럼 가정하여 코드 구현
- 저장소 계층의 변경 사항이 다른 계층에 영햔을 주지 않음
- 저장소 계층 메서드
- add(), create() : 새 원소를 저장소에 추가
- get(), find() : 이전에 추가한 원소를 저장소에서 가져옴.
- 장점
- 단위 테스트를 위한 가짜 저장소를 쉽게 만들 수 있음
- 객체를 table에 mapping하는 과정을 원하는대로 제어 => DB 스키마의 단순화
- 저장소 계층에 ORM을 사용 => 다른 데이터베이스로 쉽게 전환 가능
- 단점
- ORM 매핑을 수동으로 하려면 개발 코스트가 많이 소모
3-Layered Architecture 로직
1. 클라이언트(Client)가 어플리케이션에 요청(Request)을 보냅니다.
2. 요청(Request)을 URL에 알맞은 컨트롤러(Controller)가 수신 받습니다.
3. 컨트롤러(Controller)는 요청을 처리하기 위해 서비스(Service)를 호출합니다.
4. 서비스(Service)는 필요한 데이터를 가져오기 위해 저장소(Repository)에게 데이터를 요청합니다.
5. 서비스(Service)는 저장소(Repository)에서 가져온 데이터를 가공하여 컨트롤러(Controller)에게 데이터를 전달합니다.
6. 컨트롤러(Controller)는 서비스(Service)의 결과물(Response)을 클라이언트(Client)에게 전달해줍니다.
