클린 아키텍처

아키텍처의 중요성

긴급한 일(변경 요청)에 밀려 중요한 일, 예를 들어 아키텍쳐를 어기거나 아키텍처 없이 개발을 시작하는 미련한 짓을 하지마라. 책에서 제시하는 우선 순위는 다음과 같다. 

1. 긴급하면서 중요한 일
2. 중요한 일
3. 긴급한 일
4. 이도 저도 아닌 일

 

 

 

인터페이스를 사용하자.

import 할 때 구체 클래스를 import 하지마라.

• 현실적으로 가능한가? 실제로는 시도조차 해본적이 없기 때문에 그렇게 생각하는 것 같기도하다. 다음 프로젝트에서는 적용해보는게 좋을 듯 싶다.

 

 

 

결합도를 낮춰라.

의존성을 낮추는 것의 목표 : 변동성의 격리

의존성을 낮추는 방법 : 순환 의존성을 없애라. [117p]

class 간에 양방향 관계를 없애야한다. [78p]

• 롬복을 적용할 시 toString, hashCode 계산에서 스택 오버 플로우 문제도 있고, 이는 확실히 지키는 것이 좋아보인다. 다만 JPA를 사용하다보면 Bidirection 이 생기는 경우도 있는데, 고민해볼 여지가 있다고 생각한다.

 

 

SOLID

 

 

 

컴포넌트 설계 원칙

컴포넌트의 의존성은 반드시 저차원 -> 고차원 이여야한다.

 

 

 

아키텍터를 위한 조언

• 아키텍터도 결국 프로그래머라는 것을 잊지마라.
• 배포 전략도 고민할 수 있어야한다.
• 시스템을 컴포넌트 단위로 분할해라.
• 가짜 중복과 진짜 중복을 구별해라. 가짜 중복은 괜찮다.
• 컴포넌트, 모듈간의 경계, 선을 긋는 기술은 결합도를 낮춘다.
• 객체 관점에서 선을 잘 긋는 다는 것은 곧 SOLID 의 SRP 를 지키는 일이기도하다.
• 플러그인 아키텍처를 반영해라. 예를 들어 데이터 베이스의 종류에 의해 소프트웨어가 영향을 받아선 안된다.
• 오버 엔지니어링과 언더 엔지니어링 사이의 균형을 잘 잡아라.

 

 

 

아키텍처 정리 [330p]

모든 아키텍처의 목표는 관심사의 분리다. [214p]

1. 계층형 아키텍처
   • web, service, domain 으로 분리한다. 
     • web : controller
     • service : service interface + service implement
     • domain : repository interface + repository implement
   • 의존성은 web -> service -> domain 이다. 일반적으로 아키텍처를 알려줄 때 가장 먼저 배우는 대중적인 아키텍처 구조이기도 하다.
   • 문제점 : 아키텍처 스타일을 강요하지 못하기 때문에 controller 에서 repository 를 참조할 수도 있다. 이를 허용하는 경우(완화된 계층형 아키텍처)라면 모르겠지만 일반적으로 계층구조를 우회하는 것은 바람직하지 못하다. 이를 컴파일러 레벨에서 강제하지 못한다. (스택 오버 플로우에 위와 비슷한 논의가 있었는데, 결론은 다르게 났다. 개인적으로는 저자의 말이 좀 더 맞는 것 같다. (링크))
2. 포트 어뎁터 아키텍처
   • web, domain, database 으로 분리한다. 
     • web : controller
     • domain : service interface + service implement + port interface
     • database : repository adapter
   • 런타임에 database 를 의존 받게 할 수도 있다. 
   • 문제점 : 의존성이 web -> domain <- database 이
3. 컴포넌트 기반 아키텍처
   • web, domain 으로 분리한다. 
     • web : controller
     • domain : service interface + service implement + port interface + repository adapter
   • 의존성이 web -> domain 으로 한방향이다. 

 

 

 

Humble 객체 패턴

클래스를 테스트가 쉬운 부분과 어려운 부분을 분리하는 패턴.

테스트가 어려운 부분의 클래스가 Humble 이다.

예를들어 화면을 그리는 클래스가 있다고 하자. GUI 는 테스트하기 어려운 부분이다.

이 클래스는 GUI 를 그리는 Vie 클래스와 GUI 를 그리기 위해 데이터를 처리하는 Presentor 클래스로 분리할 수 있다. 

참고) 컴포넌트 (아키텍쳐) 경계를 이런식으로 나눌 수도 있다.

• View
• Presentor
• Interactor
• Controller

 

 

 

테스트 설계는 필수다.

테스트 설계가 잘 안 되어 있을 경우

1. 테스트가 깨지기 쉽다.
2. 특정 테스트의 변경이 다른 테스트에 영향을 준다.
3. 시스템이 뻣뻣해진다.

 

 

 

하드웨어, 펌웨어, 소프트웨어의 의미를 생각해라.

소프트웨어는 soft 해야한다.

소프트웨어를 구현하는데, 동작 구현에만 집중하면 펌웨어가 된다.

펌웨어를 만드는 경우라고 해도 프로그램이 뻣뻣해져선 안된다.

 

 

 

기타

• 제발 코드에 SQL 을 심어 넣지마라.
• 프레임워크는 클린 아키텍처를 보장하지 않는다. 
• 테스트는 업무 규칙 (비즈니스 로직을 이렇게 번역한 듯 싶다.) 에 집중해야한다.
• 함수형 프로그래밍의 장점 : 변수가 immutable 하면 race condition 이 생길 일도 없을것이다.

 

 

추가 사견

• 프레임워크가 없이도 아키텍처 설계만으로 개발할 힘이 필요하다는 듯 싶다.