728x90
반응형
목차
개요
일반적인 개발자들이 생각하는 레이어드 아키텍처란 무엇이며, 그로 인해 발생하는 문제점을 살펴본다.
8.1 레이어드 아키텍처의 최소 조건
: 레이어드 아키텍처란?
- 레이어드 아키텍처는 애플리케이션을 레이어로 나누고 각 레이어에 역할을 정한다.
- 대표적인 레이어에는 프레젠테이션, 비즈니스, 인프라스터럭처와 같은 레이어가 있다.
: 한 가지 유념해야할 사실
- 레이어드 아키텍처를 만든 사람은 존재하지 않는다.
- 레이어드 아키텍처는 누군가의 철학에 의해 만들어진 아키텍처가 아니다.
- 레이어드 아키텍처는 여러 개발자의 필요에 의해 발전된 아키텍처이다. 그래서 레이어드 아키텍처를 이해하는 깊이와 수준이 개발자마다 천차만별이다.
: 레이어드 아키텍처는 다음과 같은 사항을 지키는 것이 중요하다
- 레이어 구조를 사용한다.
- 레이어 간 의존 방향은 단방향으로 유지한다.
- 레이어 간 의존 방향이 양방향이 되면 레이어가 사라진다.
- 레이어 간 통신은 인접한 레이어에서만 이뤄지게 한다.
: 아키텍처란 무엇일까 ?
- “아키텍처란 무엇일까”에 대한 정답은 없다. 질문이 원론적이고 추상적이기에 실제로 정답이 없기 때문이다.
- 아키텍트들이 아키텍처를 설명할 때 말하는 한 가지 특징
- 아키텍처는 정책과 제약 조건을 이용해 목적을 달성합니다.
- 아키텍처는 제약조건을 이용해 개발자가 해도 되는 것과 하지말아야하는 것을 결정한다.
- 더 나아가 해서는 안되는 일이 개발 단계에서 일어나지 않게 원칙적으로 차단한다.
: 아키텍처는 형태가 아니라 정책에 가깝다.
- 코드베이스에 일관된 규칙을 적용함으로써 코드를 일관되게 유지할 수 있다. 즉, 규칙이 설계를 만든다.
: 아키텍처를 적용한다는 것
- 정책과 제약을 정하는 과정이라고 해석 (저자 왈)
- 아키텍처를 적용한다는 것은 제약 조건을 만든다는 것이며, 이를 프로젝트에 적용해 코드를 일관되고 논리적으로 만드는 것이라고 생각
8.2 잘못된 레이어드 아키텍처
: 레이어드 아키텍처를 따르는 프로젝트에서 생길 수 있는 문제점과 한계
- JPA나 데이터베이스를 우선시하는 방향
- 데이터 베이스 위주의 사고를 하게 만든다.
- 인프라스트럭처를 먼저 만들면 무슨 문제가 있나?
- 테이블이 먼저 만들어지지 않을 경우 아무런 개발도 시작할 수 없게 하는 것, 다시 말해 JPA 엔티티와 그 기반이 만들어지기 전까지 아무런 작업을 시작할 수 없다.
- 기능을 만들기 위해서 데이터베이스가 먼저 만들어져야 한다는 말은 소프트웨어 개발 의사결정에 데이터베이스가 깊이 관여한다는 의미다.
- 결론적으로 이러한 접근법은 애플리케이션 요구사항에 맞는 데이터베이스가 선정되는 것이 아니라 데이터베이스에 맞는 기능을 개발하는 방향으로 발전할 수 밖에 없다.
- 이런 상황을 프로그램이 데이터베이스에 종속됐다고 한다.
- API 우선으로 개발하는 방식
- 이 접근법은 시스템에 어떤 것이 필요한지 고민한다는 의미에서 데이터베이스 접근법보다 낫다.
- 이 방식의 접근은 결국 시스템이 특정 프레임 워크에 종속되는 결과를 낳는다. 또한 데이터 위주의 생각을 먼저 하게 될 가능성이 높다.
- 이상적으로 이러한 기술 스펙은 도메인 요구사항을 분석하고 거기에 대응하는 해결 수단으로 선택돼야 하는 것이 맞다.
: 본질을 다시 생각하기
- 레이어드 아키텍처 구조에서 상향식 접근 방식이든 하향식 접근 방식이든 썩 괜찮은 결과를 얻지 못한다.
- 애플리케이션이 특정 기술에 종속되지 않아야 한다
- 그러기 위해선 순수 자바 코드로 객체지향적인 애플리케이션을 먼저 만들 수 있어야 한다
- 스프링 같은 웹 프레임워크나 JPA 같은 영속성 라비으러리는 그 애플리케이션에 얹힐 뿐이다.
: 애플리케이션의 본질은 도메인
- 애플리케이션을 개발한다는 것은 도메인을 파악하고, 이에 따른 도메인 모델을 구성하고, 도메인 모델을 표현하는데 적합한 언어를 선택하고, 도메인 모델을 만들고, 도메인 기능을 제공할 기술을 선택한다는 것이다.
8.3 진화하는 아키텍처
: 상향식 접근도 하향식 접근도 아닌 레이어드 아키텍처 개발
- 시스템 개발의 첫 시작을 도메인으로 두면 된다. 도메인의 분석과 도메인 개발에서 출발해야한다.
: 인지 모델 변경하기
- 도메인을 개발하려면 비즈니스 레이어부터 개발하면 된다.
- “비즈니스 레이어”는 도메인까지 포함하는 개념이다. 도메인이란 비즈니스 영역이다. 그러니까 도메인은 비즈니스 레이어에 포함되는 개념이 맞다.
- 따라서 애플리케이션 개발을 위한 첫걸음으로 비즈니스 레이어, 그리고 비즈니스 레이어 중에서도 도메인을 가장 먼저 개발해야한다.
: 도메인 레이어 추가하기
- 도메인 레이어는 비즈니스 도메인을 표현하는 클래스가 모이는 곳이다. 이 공간의 객체들은 역할과 책임을 가지고 서로 협력한다.
- 도메인 레이어의 객체지향적인 도메인 모델들이 위치하는 공간이다.
- 도메인 레이어의 목적은 애플리케이션에서 사용하는 주요 도메인 객체들을 표현하는 것이다
- 도메인 레이어에 있는 객체들을 작성할 떄는 “순수 자바 코드”로 작성해야 한다.
- 이것은 도메인 레이어를 외부 라이브러리에 의존하지 않고 자유롭게 만들기 위함이다.
: 패키지와 레이어는 다르다
- 레이어를 표현하기 위한 수단으로 패키지를 사용할 수 있지만 그렇다고 해서 패키지 하나하나가 레이어드 아키텍처의 모든 레이어에 대응해야만 하는 것은 아니다.
- 레이어드 아키텍처에서 말하는 레이어라는 것은 패키지나 모듈 같은 형태가 아니라 개념이다.
💡불변 객체의 값을 변경하고 싶을 떄
- 불변 값의 수정자는 새로운 객체를 반환한다는 의미를 담아 전치사 with로 메서드 이름을 시작하기도 한다.
: 도메인 레이어에 대해 주의할 점
- 도메인 레이어는 인프라스트럭 레이어 위에 존재하지만 도메인 레이어는 인프라스트럭처 레이어를 참조하지 않는다
- 즉, 도메인 레이어는 JPA 라이브러리나 스프링 라이브러리를 임포트해서는 안된다. 이는 도메인 레이어와 다른 레이어와의 결합을 완전히 끊어내기 위함이다.
8.4 새로운 접근법
: 도메인부터 시작하는 개발 방법을 어떤 접근법이라고 불러야 할까?
- 아키텍처를 보면서 아키텍처가 어떻게 생겼는지 외우는 것보다 아키텍처를 해석할 수 있는 것이 우선이다.
- “왜 이런 형태를 띠고 있는지”가 중요하다
8.5 빈약한 도메인
여러모로 단순한 애플리케이션을 만드는데 복잡한 아키텍처를 적용하는 것은 오버 엔지니어링에 속한다.
프로젝트의 성공 실패를 장담할 수 없는 상황이라면 복잡한 아키텍처와 유연한 설계보다 고정된 기술 스택과 직관적인 아키텍처를 사용하는 편이 더 낫다.
728x90
반응형
