클린 코드(Clean Code)/만들면서 배우는 클린 아키텍처 요약
-
12장 - 아키텍처 스타일 결정하기클린 코드(Clean Code)/만들면서 배우는 클린 아키텍처 요약 2023. 3. 11. 00:01
언제 육각형 아키텍처 스타일을 사용하고, 전통적인 계층형 아키텍처 스타일을 사용해야 할까? 도메인이 왕이다 외부 시스템에 대한 의존성 등의 변화로부터 자유롭게 도메인 코드를 개발할 수 있는 것이 육각형 아키텍처 스타일의 주요 특징이라는 것은 명확합니다. 영속성이나 다른 기술적인 측면에 대해서 함께 생각할 필요가 없어지게 되면서 도메인에 대해 가장 잘 고려할 수 있게 됩니다. 만약 도메인 코드가 애플리케이션에서 가장 중요한 것이 아니라면 이 아키텍처 스타일은 필요하지 않습니다. 경험이 여왕이다 과거에 했던 일에 편함을 느끼는데 무언가를 바꿀 이유를 있을까? 육각형 아키텍처에 대한 확신이 없다면 작은 모듈에 먼저 시도해 보는 것이 좋습니다. 이후에 자신만의 아이디어를 추가해서 편하게 느껴지는 스타일로 개발하..
-
11장 - 의식적으로 지름길 사용하기클린 코드(Clean Code)/만들면서 배우는 클린 아키텍처 요약 2023. 3. 10. 00:01
지름길을 방지하기 위해서는 먼저 지름길 자체를 파악해야 합니다. 소프트웨어는 말랑말랑하기(쉽게 변경될 수 있기) 때문에 지름길을 먼저 취하고 나중에 고치는 것이 더 경제적일 수 있습니다. 왜 지름길은 깨진 창문 같을까? 깨진 창문 이론이란? 번호판 없는 차 한 대를 주거환경이 높고 낮은 환경에 주차하였을 때 주거환경이 낮은 곳에서는 24시간이 지나기 전에 중요 부품들이 도난당했으며 주거환경이 높은 곳에서는 일주일 동안 전혀 손을 타지 않았습니다. 하지만 일부로 창문을 깨뜨리자 짧은 시간동안 행인들에 의해 망가졌습니다. 이로 2가지를 알 수 있습니다 - 기물 파손이 흔한 동네에서는 방치된 차를 도둑질하거나 망가뜨리는 일이 더 쉽게 일어난다. - 좋은 동네라도 차의 창문이 깨져있다면 차를 망가뜨리는 일이 쉽..
-
10장 - 아키텍처 경계 강제하기클린 코드(Clean Code)/만들면서 배우는 클린 아키텍처 요약 2023. 3. 9. 00:01
일정 규모 이상의 모든 프로젝트에서는 시간이 지나면서 아키텍처가 서서히 무너지게 됩니다. 계층 간의 경계가 약화되고, 코드는 점점 더 테스트하기 어려워지게 됩니다. 해당 장에서는 아키텍처 내의 경계를 강제하는 방법과 아키텍처 붕괴에 맞서 싸우기 위해 취할 수 있는 전략을 살펴보고자 합니다. 경계와 의존성 경계를 강제한다는 것은 어떤 것을 의미할까요? 의존성 규칙에 따르면 경계는 항상 안쪽으로 향해야 합니다. 1. 접근제한자 public, private, protected에 대해서만 대부분 알고 있으며 default 제한자를 잘 모릅니다. default 제한자는 패키지를 통해 클래스들을 응집적인 모듈로 만들어줍니다. 모듈 내의 클래스들은 서로 접근 가능하지만 패키지 바깥에서는 접근할 수 없습니다. 이제 모..
-
9장 - 애플리케이션 조립하기클린 코드(Clean Code)/만들면서 배우는 클린 아키텍처 요약 2023. 3. 3. 00:01
조립을 신경 써야 하는 이유 코드 의존성을 모두 도메인 방향으로 향하기 위해서입니다. 설정 컴포넌트 모든 클래스에 대한 의존성을 가지는 설정 컴포넌트가 있어야 합니다. 이 클래스는 단일 책임 원칙을 위반하지만 애플리케이션의 나머지 부분을 깔끔하게 유지하기 위해서는 필요합니다. 스프링의 클래스패스 스캐닝으로 조립하기 스프링을 통해 애플리케이션을 조립한 결과물을 application context라고 합니다. 애플리케이션 컨텍스트는 애플리케이션을 구성하는 모든 객체(bean)를 포함합니다. 스프링은 @Component가 붙은 클래스를 찾아 객체를 생성합니다. 적절한 곳에 애너테이션을 활용하여 생성자만 잘 만들어주면 됩니다. @Component를 포함하고 있는 @PersistenceAdapter라는 사용자 애..
-
8장 - 경계 간 매핑하기클린 코드(Clean Code)/만들면서 배우는 클린 아키텍처 요약 2023. 3. 2. 00:01
매핑에 찬성하는 개발자 두 계층을 매핑하지 않으면 양 계층을 같은 모델에 사용해야 하고 두 계층이 강하게 결합된다. 매핑에 찬성하지 않는 개발자 매핑을 위해 너무 많은 보일러플레이트 코드가 생성된다. 많은 유스케이스들이 오직 CRUD만 수행하고 계층에 걸쳐 같은 모델을 사용하기 때문에 계층 사이의 매핑은 과하다 매핑하지 않기 전략 영속성 계층과 유스케이스에서 모두 Account 객체를 사용하는 경우입니다. 이렇게 REST를 위한 JSON 직렬화 애너테이션 또는 ORM 프레임워크를 위한 애너테이션이 필요하게 됩니다. 이렇게 되면 Account 객체에서 웹, 영속성과 관련된 특수한 요구사항에 관심이 없음에도 불구하고 모든 요구사항을 다루게 됩니다. 이제 Account 클래스는 웹, 애플리케이션, 영속성 계층..
-
7장 - 아키텍처 요소 테스트하기클린 코드(Clean Code)/만들면서 배우는 클린 아키텍처 요약 2023. 3. 1. 00:01
이번장에서는 육각형 아키텍처의 각 요소들을 테스트할 수 있는 테스트 유형에 대해 논의합니다. 단위 테스트로 도메인 엔티티 테스트하기 Account의 상태를 특정 시점의 계좌 잔고와 그 이후 입출금 내역으로 구성되어 있습니다. withdraw() 메서드가 기대한 대로 동작하는지 검증하려면 단지 도메인 엔티티인 Account를 인스턴스화 하고 메서드를 호출하여 출금이 성공하는지 검증하고 객체의 상태에 기대되는 부수효과들이 잘 일어났는지 확인하는 단순한 단위 테스트를 수행할 수 있습니다. 도메인 엔티티는 다른 클래스에 거의 의존하지 않기 때문에 다른 종류의 테스트는 필요하지 않습니다. 단위 테스트로 유스케이스 테스트하기 테스트 가독성을 높이기 위해 given/when/then 섹션으로 나누어 작성하였습니다. ..
-
6장 - 영속성 어댑터 구현하기클린 코드(Clean Code)/만들면서 배우는 클린 아키텍처 요약 2023. 2. 26. 00:01
애플리케이션 서비스에서는 영속성 기능을 사용하기 위해 포트 인터페이스를 호출합니다. 이 포트는 실제로 영속성 작업을 수행하고 데이터베이스와 통신할 책임을 가진 영속성 클래스에 의해 구현됩니다. 영속성 어댑터는 주도되는 어댑터이며 애플리케이션에 의해 호출될 뿐, 애플리케이션을 호출하지 않습니다. 영속성 어댑터의 책임 - 입력을 받는다 - 입력을 데이터베이스 포맷으로 매핑한다 - 입력을 데이터베이스로 보낸다 - 데이터베이스 출력을 애플리케이션 포맷으로 매핑한다 - 출력을 반환한다 포트 인터페이스 분리하기 ISP에 의거하여 하나의 비대한 포트를 갖는 것보다 서비스가 실제로 필요한 메서드만 사용하는 것이 좋습니다. 영속성 어댑터 분리하기 영속성 어댑터 클래스도 기능에 따라 경계를 나눌 수 있습니다. 스프링 데이..
-
5장 - 웹 어댑터 구현하기클린 코드(Clean Code)/만들면서 배우는 클린 아키텍처 요약 2023. 2. 25. 00:01
웹 어댑터는 주도하는 인커밍 어댑터입니다. 외부로부터 요청을 받아 애플리케이션 코어를 호출하고 무슨 일을 해야 할지 알려줍니다. 이때 제어 흐름은 웹 어뎁터에 있는 컨트롤러에서 애플리케이션 계층에 있는 서비스로 흐릅니다. 어댑터의 책임 - HTTP 요청을 자바 객체로 매핑 - 권한 검사 - 입력 유효성 검증 - 입력을 유스케이스의 입력 모델로 매핑 - 유스케이스 호출 - 유스케이스의 호출을 HTTP로 매핑 - HTTP 응답을 반환 HTTP와 관련된 것은 애플리케이션 계층으로 침투해서는 안됩니다. 컨트롤러 나누기 컨트롤러는 너무 적은 것보다는 너무 많은 게 낫습니다. 클래스 코드가 많아지게 되면 파악하는데 난이도가 높아지게 됩니다. 가급적 메서드와 클래스명은 유스케이스를 최대한 반영해 지어내고 별도의 컨트..