데이터베이스
데이터 구조와 데이터 모델은 아키텍처적으로 중요하지만 데이터베이스는 중요치 않은 세부 사항이다. 이들을 동일 선상에 놓고 생각하지 않도록 주의해야 한다.
웹
GUI는 세부사항이다. 웹은 GUI이므로 세부사항이다. 따라서 업무 로직에서 분리되어야 한다. GUI와 애플리케이션을 분리하긴 힘들지만 이들의 최종 결과를 가지고 유스케이스를 실행하고 그 결과를 다시 GUI와 애플리케이션에게 던져주는 것으로 입출력을 분리시킬 수 있다.
모바일의 경우를 생각한다면 View와 ViewModel을 묶어 서로 지지고 볶게 하고 유스케이스를 의존하게 만드는게 좋을 것 같다.
프레임워크
프레임워크는 사용하기 시작하면 일방적으로 개발자가 프레임워크에 종속되기 때문에 신중하게 선택해야 한다. 프레임워크를 선택한 이후에도 업무 로직은 프레임워크와 분리되어 동작하도록 개발해야 한다.
TypeORM에서 엔티티는 데코레이터를 통해 데이터베이스 스키마와 연동되어 버리는데 이것도 안티 패턴인 것일까? 세부사항인 데이터베이스가 시스템에 종속되는 것이니까 괜찮은 것 같기도 하고 데이터 클래스에 TypeORM이라는 프레임워크의 데코레이터가 들어가니까 안좋은 것 같기도 하고 헷갈린다.
코드 구조
계층 기반 패키지
[Controller] -[->Service(Interface) <- ServiceImpl -]-> [Repository(Interface) <- RepositoryImpl]
코드가 하는 일에 기반해 코드를 분리. 처음 시작하기에 적합한 구조이지만 소프트웨어가 커지기 시작하면 좀 더 잘게 모듈화가 필요하다. 또한 패키지 자체로는 도메인에 대해 알 수 없다는 문제가 있다.
기능 기반 패키지
[Controller -> Service(Interface) <- ServiceImpl -> Repository(Interface) <- RepositoryImpl]
서로 연관된 기능(도메인)을 기준으로 코드를 분리. 동일 기능이 한 패키지에 담겨 있기 때문에 변경 작업이 수월할 수 있다.
포트와 어댑터
[Controller] -[-> Service(Interface) <- ServiceImpl -> Orders(Interface) <-]- [RepositoryImpl]
내부(도메인)영역과 외부(인프라)영역으로 코드를 분리. 상세 구현은 별도의 패키지로 분리되고 업무 규칙과 필요한 인터페이스들을 패키지로 묶는다.
컴포넌트 기반 패키지
[Controller] -[-> Component(Interface) <- ComponentImpl -> Repository(Interface) <- RepositoryImpl]
업무 규칙과 영속성 관련 코드를 하나의 컴포넌트로 묶고 외부에서는 컴포넌트 인터페이스를 통해서만 접근하도록 코드를 분리.
계층기반과 포트와 어댑터 방식의 코드 분리는 데이터 접근 파트를 별도의 패키지로 분리했기 때문에 컨트롤러에서 직접 데이터에 접근하는 상황을 야기시킬 수 있으므로 기능기반 혹은 컴포넌트 기반으로 코드를 분리하는 것이 좋을 것 같다.
중요!
계층을 어떤 방식으로 분리하던 클래스를 모두 public으로 선언한다면 어떤 계층을 사용하던 같은 것이 되어 버린다. 적절하게 접근을 제어하는 것이 중요!
