어플리케이션 설계 원칙 ( SOLID / 클린 아키 텍쳐 )

SOLID 

2000년대 초반 로버트C. 마틴이 객체 지향프로그래밍 및 설계에 대한 SOLID 라는 5가지 원칙을 소개함

1. 단일 책임 원칙 ( Single Responsibility Principle )

- 단일 책임은 어떤 클래스나 모듈 또는 메서드가 단 하나의 기능을 가져야 한다는 뜻.

=> 어떤 변경 사항이 발생하더라도 그 변경 사항에 대한 책임이 있는 부분만 수정하면 된다.

ex ( 분석 + 서버전송 )   =>  (분석)   ( 서버전송 ) 

2. 개방 - 폐쇄 원칙 ( Open Closed Principle )
- 시스템의 구조를 올바르게 구성하여, 변경사항이 발생하더라도 다른코드나, 모듈에 영향이 없도록 해야한다.

=> 확장성을 높이고, 수정에는 폐쇄적이어야 한다.

 

3. 리스코프 치환 원칙 ( Liskov Suvstitution Principle )

- 클래스 B 가  클래스 A의 자식클래스라면,  부모인 클래스 A를 자식인 클래스 B로 치환해도 문제가없어야 한다.

=> 다운캐스팅된 인스턴스가 논리적으로 그 역할이 문제가 없어야 한다.

 

4. 인터페이스 분리 원치 ( Interface Segregation Principle )

- 큰 덩어리의 인터페이스들을 구체적이고 작은 단위로 분리함으로써, 클래스들이 꼭 필요한 메서드만 이용할 수 있어야 한다.

ex.  새를 예로 들었을때  fly(), cry() 라는 움직임있다고 했을때,  펭귄으 경우 새지만 날지 못한다고 한다면, fly()이라는 인터페이스의 메소드가 필요 없게 된다.

 

5. 의존 역전 원칙 ( Dependency Inversion Principle )

- 상위 계층이 하위 계층에 의존하는 의존관계를 역전 시킴으로, 상위 계층이 하위 계층의 구현으로 부터 독립 되게 할 수있다.

 

클린 아키텍처

Robert C Martin 블로그의 글에서는 대부분의 아키텍처는 세부적인 차이는 있어도 공통적인 목표는 계층을 분리하여 관심사의 분리하는 것이라고 말하는데, 이런 아키텍처가 동작하기 위해서는 의존성 규칙을 지켜야 한다고 합니다.

 

의존성 규칙은 모든 소스코드 의존성은 반드시 외부에서 내부로, 고수준 정책을 향해야 한다고 말합니다. 즉 업무의 업무 로직을 담당하는 코드들이 DB 또는 Web 같이 구체적인 세부 사항에 의존하지 않아야 합니다. 이를 통해 업무 로직(고수준 정책)은 세부 사항들(저수준 정책)의 변경에 영향을 받지 않도록 할 수 있습니다.

 

1. Entities

- 데이터의 구조나, 메서드를 포함하는 객체 

 

2. Use Cases

- 애플리션과 관련된 비지니스 규칙을 포함 하고, 시스템의 모든 유스 케이스 구현체들을 캡슐화 함

- UI나 프레임워크같은 외부 계층으로 부터 영향을 받지 않는다.

ex ) Model, Repository, Executor

 

3. Interface Adapters

- 유스 케이스나 엔터티로부터 얻은 데이터를 가공하는 계층.

- 비지니스 로직을 수행하여 원하는 결과값을 얻어 UI에 표현하려고 적당한 형식으로 데이터를 가공

- UI로 부터 얻은 데이터를 내부 DB나 원격서버에 전송할 때도 이계층에서 전달

ex ) Presenter, View, ViewModel, Controller