김동형수 개발기

아키텍처 스타일 결정하기 도메인이 왕이다 헥사고날 아키텍처는 영속성 관심사나 외부 시스템에 의한 의존성 등의 변화로부터 자유롭다. 외부의 영향을 받지 않고 도메인 코드를 자유롭게 발전시킬 수 있다는 것은 육각형 아키텍처 스타일이 내세우는 가장 중요한 가치다. 영속성 문제나 다른 기술적인 측면에 대해서 함께 생각할 필요가 없게 되면 도메인에 대해 가장 잘 고려할 수 있게 된다. DDD(도메인 주도 개발) 도메인을 중심에 두는 아키텍처 없이는, 도메인 코드를 향한 의존성을 역전시키지 않고서는, DDD를 제대로 할 가능성이 없다. 도메인 코드가 애플리케이션에서 가장 중요한 것이 아니라면 이 아키텍처 스타일은 필요하지 않을 것이다. 경험이 왕이다 경험에 의해서 습관처럼 계층형 아키텍처 스타일을 이용한다. 과거에..

의식적으로 지름길 사용하기 잠재적인 지름길에 대한 인식을 높이고 그 영향에 대해 이야기한다. 이 정보만 있어도 우발적으로 사용되는 지름길을 인식하고 수정할 수 있다. 정당한 지름길이라면 지름길의 효과를 의식적으로 택할 수도 있다. 어떤때는 (의식적으로)지름길을 먼저 취하고 나중에 고치는 것이(혹은 아예 고치지 않더라도) 실제로 더 경제적일 수도 있다. 왜 지름낄은 깨진 창문 같을까? 깨진 창문(유리창) 이론 : 깨진 유리창 하나를 방치해 두면, 그 지점을 중심으로 범죄가 확산되기 시작한다는 이론으로, 사소한 무질서를 방치하면 큰 문제로 이어질 가능성이 높다는 의미를 담고 있다. 출처 - https://ko.wikipedia.org/wiki/%EA%B9%A8%EC%A7%84_%EC%9C%A0%EB%A6%A..

아키텍처 경계 강제하기 일정규모 이상의 프로젝트에서는 시간이 지나면서 아키텍처가 서서히 무너지게 된다. 계층간의 경계가 약화되고 코드는 점점 더 테스트하기 어려워진다. 이번 장에서는 아키텍처 내의 경계를 강제하는 방법과 아키텍처 붕괴에 맞서는 몇가지 조치를 살펴본다. 경계와 의존성 애플리케이션 계층은 애플리케이션 서비스안에 유스케이스를 구현하기 위해 도메인 엔티티에 접근한다. 어댑터는 인커밍 포트를 통해 서비스에 접근, 반대로 서비스는 아웃고잉 포트를 통해 어댑터에 접근한다. 설정 계층은 어댑터와 서비스 객체를 생성할 팩터리를 포함하고 있고, 의존성 주입 메커니즘을 제공한다. 아키텍처의 경계는 명확하다. 각 계층 사이, 안쪽 인접 계층과 바깥쪽 인접 계층 사이에 경계가 있다. 의존성은 항상 안쪽 방향으로..

애플리케이션 조립하기 애플리케이션이 시작될 때 클래스를 인스턴스화하고 묶기 위해서 의존성 주입 메커니즘을 이용한다. 평범한 자바, 스프링, 스프링 부트 프레임워크에서 각각 어떻게 하는지 살펴본다. 왜 조립까지 신경 써야 할까? 코드의존성이 올바른 방향을 가리키게 하기 위해서 모든 의존성은 안쪽으로 ( 웹 -> 영속성 ) 유스케이스가 영속성 어댑터를 호출하는 케이스를 만들지 않기 위해서 아웃고잉 포트 인터페이스 생성 유스케이스는 인터페이스만 알고(참조하고) 있어야한다. 헥사고날 아키텍처의 유익한 부수효과 중 하나는 코드를 휠씬 쉽게 테스트할 수 있는 것이다. 의존성이 있는 모든 객체를 생성자로 전달할 수 있다면 mock으로 전달할 수 있고 이는 격리된 단위 테스트를 생성하기가 쉬워진다. 설정 컴포넌트는 애..

경계 간 매핑하기 매핑에 관한 논쟁 매핑에 찬성하는 개발자 : 두 계층 간에 매핑을 하지 않으면 양 계층에서 같은 모델을 사용해야 하는데 이렇게 하면 두 계층이 강하게 결합된다. 매핑에 반대하는 개발자 : 두 계층간에 매핑을 하게 되면 보일러플레이트 코드를 너무 많이 만들게 된다. 많은 유스케이스들이 오직 CRUD만 수행하고 계층에 걸쳐 모델을 사용하기 때문에 계층 사이의 매핑은 과하다. 매핑을 결정하는데 도움이 되도록 매핑 전략의 장단점을 살펴본다. '매핑하지 않기' 전략 웹 컨트롤러에서 SendMoneyUseCase 인터페이스 호출해서 유스케이스 실행 인자로 Account 객체를 갖는다. 웹, 애플리케이션 계층 모두에서 Account 클래스에 접근해야한다. 영속성 계층과 애플리케이션 계층도 같은 관계..

아키텍처 요소 테스트하기 헥사고날 아키텍처에서 테스트 전략에 대해 이야기한다. 아키텍처의 각 요소들을 테스트할 수 있는 유형에 대해 논의한다. 테스트 피라미드 테스트의 지향하는 방향 만드는 비용을 적게 유지보술르 쉽게 실행속도가 빨라야한다 작은 크기의 테스트들에 대해 높은 커버리지를 유지 테스트의 비용이 높아질 수록 커버리지의 목표를 낮게 잡아야한다. 1. 단위테스트는 피라미드의 토대에 해당한다. 하나의 클래스를 인스턴스화하고 클래스의 인터페이스를 통해 기능들을 테스트한다. 만일 의존되는 클래스가 있다면 테스트하는 동안 모킹해서 사용한다. profile을 이용해서 구현체를 나눌 수 있는데, 이때 test profile일 경우 mocking하는 구현체를 작성하면 될 것 같다. 2. 통합테스트는 연결된 여러..

영속성 어댑터 구현하기 전통적인 계층형 아키텍처는 영속성에 의존하게 되면서 '데이터베이스 주도 설계'가 되는데, 이러한 의존성을 역전시키기 위해 영속성 계층을 어플리케이션 계층의 플러그인으로 만드는 방법을 살펴본다. 의존성 역전 애플리케이션 서비스에서 영속성 기능을 사용하기 위해서 인터페이스를 호출하고 실제 데이터베이스와 통신할 책임을 가진 클래스는 영속성 어댑터 의해 구현된다. 포트는 애플리케이션 서비스와 영속성 계층간 의존성을 없애기 위한 간접 계층이다. 영속성 계층 코드를 변경하는 중 버그가 생기면 애플리케이션 코어가 제 기능을 하지 못한다. 하지만 중간계층인 포트가 기대하는 역할을 한다면 영속성 계층 코드에 버그가 생기더라도 애플리케이션 코어에는 영향이 없을 것이다. 영속성 어댑터의 책임 입력을 ..

02. 의존성 역전하기 객체지향 개발을 잘 하기위한 방법인 'SOLID' 원칙 중 단일 책임 원칙, 의존성 역전 원칙에 대해 다룬다. 단일 책임 원칙 'SOLID' 원칙 중 'S'에 해당하며, 일반적인 해석은 아래와 같다 하나의 컴포넌트는 오로지 한 가지 일만 해야 하고, 그것을 올바르게 수행해야 한다. 그러나 저자의 관점에서는 '책임' = '변경할 이유'라고 해석해서 단일 책임 원칙을 아래와 같이 해석한다. 컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다. 만약 컴포넌트를 변경할 이유가 한 가지라면 우리가 어떤 다른 이유로 소프트웨어를 변경하더라도 그 이유에 해당하지 않는 컴포넌트에 대해서는 신경쓸 필요가 없다. 변경할 이유라는 것은 컴포넌트 간의 의존성을 통해서 쉽게 전파가 된다. 컴포넌트간 의존성..