도서 요약

[만들면서 배우는 클린 아키텍처] 12. 아키텍처 스타일 결정하기

"만들면서 배우는 클린 아키텍처" 도서를 정리한 내용입니다. 12. 아키텍처 스타일 결정하기 도메인이 왕이다 “외부의 영향을 받지 않고 도메인 코드를 자유롭게 발전시킬 수 있다는 것은 육각형 아키텍처 스타일이 내세우는 가장 중요한 가치다” 인간은 습관의 동물 경험이 여왕이다 그때그때 다르다 어떤 아키텍처 스타일을 골라야 하나요? 그때그때 달라요 어떤 소프트웨어냐? 도메인 코드의 역할 팀의 경험 내린 결정이 마음에 드냐?

2022. 12. 22. 19:47

도서 요약

[만들면서 배우는 클린 아키텍처] 11. 의식적으로 지름길 사용하기

"만들면서 배우는 클린 아키텍처" 도서를 정리한 내용입니다. 11. 의식적으로 지름길 사용하기 과거에 하나의 실험을 진행했었다 왜 지름길은 깨진 창문 같을까? “깨진 창문 이론” “어떤 것이 멈춘 것처럼 보이고, 망가져 보이고, 혹은 관리되지 않는다고 여겨지면 인간의 뇌는 이를 더 멈추고, 망가뜨리고, 해도 된다고 생각하게 된다” 깨진 창문 이력의 적용 부분 코드 작업에 적용될 때의 의미 "이 모든 것을 고려하면 이른바 '레거시'라고 불리는 많은 코드 품질이 시간이 가면서 심하게 낮아졌다는 게 그리 놀라운 일은 아니다” 깨끗한 상태로 시작할 책임 지름길 선택 유스케이스 간 모델 공유하기 두 개의 유스케이스가 같은 입력 모델을 공유하는 예를 보여준다 “SendMoneyCommand가 변경되면 두 유스케이스..

2022. 12. 22. 19:46

도서 요약

[만들면서 배우는 클린 아키텍처] 10. 아키텍처 경계 강제하기

"만들면서 배우는 클린 아키텍처" 도서를 정리한 내용입니다. 10. 아키텍처 경계 강제하기 “모든 프로젝트에서 시간이 지나면서 아키텍처가 서서히 무너지게 된다” 이번 장에서는 아키텍처 내의 경계를 강제하는 방법과 아키텍처 붕괴에 맞서 싸우기 위해 취할 수 있는 몇가지 조치를 알아보자 경계와 의존성 '경계를 강제한다'는 것이 어떤 의미일까? "의존성 규칙에 따르면 계층 경계를 넘는 의존성은 항상 안쪽 방향으로 향해야 한다" package-private의 중요성 package-private 제한자가 왜 그렇게 중요할까? 자바 패키지를 통해 클래스들을 응집적인 '모듈'로 만들어 주기 때문이다 이러한 모듈 내에 있는 클래스들은 서로 접근 가능하지만, 패키지 바깥에서는 접근할 수 없다. 그럼 모듈의 진입점으로 활..

2022. 12. 22. 19:46

도서 요약

[만들면서 배우는 클린 아키텍처] 9. 애플리케이션 조립하기

"만들면서 배우는 클린 아키텍처" 도서를 정리한 내용입니다. 9. 애플리케이션 조립하기 의존성의 방향 유스케이스와 어댑터를 그냥 필요할 때 인스턴스화하면 안 되는걸까? 코드의 의존성이 올바른 방향을 가리키게 하기 위해서다. "애플리케이션 도메인 코드 방향으로 향해야 도메인 코드가 바깥 계층의 변경으로부터 안전하다" 영속성 어댑터를 직접 호출 영속성 어댑터를 직접 호출한다면? 잘못된 의존성 방향 코드 의존성이 잘못된 방향으로 만들어진 것이다. 또한 어댑터에 대한 목객체를 활용하여 테스트하기 쉽다. 아웃고잉 포트 인터페이스를 생성한 이유 객체 인스턴스를 생성할 책임은 누구에게? 아키텍처에 중립적이고 인스턴스 생성을 위해 모든 클래스에 의존성을 가지는 설정 컴포넌트가 그 책임을 갖는다 설정 컴포넌트 책임 웹 ..

2022. 12. 22. 19:45

도서 요약

[만들면서 배우는 클린 아키텍처] 8. 경계 간 매핑하기

"만들면서 배우는 클린 아키텍처" 도서를 정리한 내용입니다. 8. 경계 간 매핑하기 매핑에 대한 논쟁 매핑은 반드시 사용해야 합니다 두 계층 간에 매핑을 하지 않으면 양 계층에서 같은 모델을 사용해야 하는데 이렇게 하면 두 계층이 강하게 결합됩니다 매핑은 불필요해요 하지만 두 계층간에 매핑을 하게 되면 보일러플레이트 코드를 너무 많이 만들게 돼요. 많은 유스케이스들이 오직 CRUD만 수행하고 계층에 걸쳐 같은 모델을 사용하기 때문에 계층 사이의 매핑은 과합니다. '매핑하지 않기' 전략 유스케이스에서 Account 객체를 인자를 가진다. 즉 웹 계층과 애플리케이션 계층 모두 Account 클래스에 접근해야 한다. 영속성 계층과 애플리케이션 계층도 같은 관계다. '매핑하지 않기' 전략 문제점 웹, 애플리케이..

2022. 12. 22. 19:45

도서 요약

[만들면서 배우는 클린 아키텍처] 7. 아키텍처 요소 테스트하기

"만들면서 배우는 클린 아키텍처" 도서를 정리한 내용입니다. 7. 아키텍처 요소 테스트하기 테스트 피라미드 "테스트의 기본 전제" 비용이 적고, 유지보수하기 쉽고, 빨리 실행되고, 안정적인 작은 크기의 테스트에 대해 높은 커버리지를 유지해야 한다 단위 테스트로 도메인 엔티티 테스트하기 이 테스트는 만들고 이해하기 쉬운 편이고,아주 빠르게 실행된다. 단위 테스트는 도메인 엔티티에 녹아있는 비즈니스 규칙을 검증하기에 가장 적절한 방법이다. 도메인 엔티티의 행동은 다른 클래스에 거의 의존하지 않기 때문에 다른 종류의 테스트는 필요하지 않다. Account를 인스턴스화하고 withdraw() 메서드가 성공했는지 검증하는 단위 테스트 class AccountTest { @Test void withdrawalSuc..

2022. 12. 22. 19:44

도서 요약

[만들면서 배우는 클린 아키텍처] 6. 영속성 어댑터 구현하기

"만들면서 배우는 클린 아키텍처" 도서를 정리한 내용입니다. 6. 영속성 어댑터 구현하기 의존성 역전 “즉, 영속성 코드가 변경되더라도 코어 코드를 변경하지 않아도 돼” 의존성 어댑터의 책임 입력을 받는다. 입력을 데이터베이스 포맷으로 매핑한다. 입력을 데이터베이스로 보낸다. 데이터베이스 출력을 애플리케이션 포맷으로 매핑한다. 출력을 반환한다. 영속성 어댑터는 포트 인터페이스를 통해 입력을 받는다. 입력 모델은 인터페이스가 지정한 도메인 엔티티나 특정 데이터베이스 연산 전용 객체가 될 것이다. 포트 인터페이스 나누기 데이터베이스 연산을 정의하는 포트 인터페이스를 어떻게 나눌까? 하나의 포트 인터페이스에 두기 모든 데이터베이스 연산을 하나의 리포지토리 인터페이스에 넣어 두는 게 일반적인 방법이다. 넓은 범..

2022. 12. 22. 19:44

도서 요약

[만들면서 배우는 클린 아키텍처] 5. 웹 어댑터 구현하기

"만들면서 배우는 클린 아키텍처" 도서를 정리한 내용입니다. 5. 웹 어댑터 구현하기 웹 어댑터의 위치 웹 어댑터 호출 방향 직접 호출하면 어떤 문제가? 서비스에 대해 많은 것을 알 수 있고 서비스 변경에 영향을 받을 수 있다 웹 어댑터는 서비스를 직접 참조 동일 기술(프레임워크)을 사용해야 한다 포트를 통한 호출을 해보자 “서비스는 이 포트를 구현하고, 웹 어댑터는 이 포트를 호출할 수 있다” 어떤 장점이 있는가? 레거시 코드를 다루는 유지보수 엔지니어에게는 무척 소중한 정보 외부 세계와 통신할 수 있는 명세 서비스에 대해서는 몰라도 됨 의존성 역전 원칙 실시간 데이터 전송 웹 소켓으로 실시간 데이터를 사용자의 브라우저로 전송한다고 가정해보자 웹 어댑터의 책임 HTTP 요청을 자바 객체로 매핑 권한 검..

2022. 12. 22. 19:43

도서 요약

[만들면서 배우는 클린 아키텍처] 4. 유스케이스 구현하기

"만들면서 배우는 클린 아키텍처" 도서를 정리한 내용입니다. 4. 유스케이스 구현하기 코드 구현하기 앞에서 논의한 아키텍처를 실제 코드로 구현해보자 육각형 아키텍처에서 도메인 엔티티 작성으로 시작해보자 도메인 모델 구현하기 “한 계좌에서 다른 계좌로 송금하는 유스케이스를 구현해보자” package buckpal.domain; @AllArgsConstructor @Getter public class Account { private AccountId id; private Money baselineBalance; private ActivityWindow activityWindow; public Money calculateBalance() { return Money.add( this.baselineBalance..

2022. 12. 22. 19:43

도서 요약

[만들면서 배우는 클린 아키텍처] 3. 코드 구성하기

"만들면서 배우는 클린 아키텍처" 도서를 정리한 내용입니다. 3. 코드 구성하기 코드를 보는 것만으로 어떤 아키텍처인지 알 수 있으면 좋지 않을까? 계층으로 구성하기 "계층으로 코드를 구성하면 기능적인 측면들이 섞이기 쉽다" 계층으로 구성하기의 단점 1 사용자를 관리하는 기능을 추가해야 한다면, 추가적인 구조가 없다면, "아주 빠르게 서로 연관되지 않은 기능들끼리 예상하지 못한 부수효과를 일으킬 수 있는 클래스들의 엉망진창 묶음으로 변모할 가능성이 있다" 계층으로 구성하기의 단점 2 AccountService와 AccountController가 어떤 유스케이스를 구현했는지 파악할 수 있겠는가? "애플리케이션이 어떤 유스케이스들을 제공하는지 파악할 수 없다" 기능으로 구성하기 "기능을 기준으로 코드를 구성..

2022. 12. 22. 19:42

도서 요약

[만들면서 배우는 클린 아키텍처] 2. 의존성 역전하기

"만들면서 배우는 클린 아키텍처" 도서를 정리한 내용입니다. 2. 의존성 역전하기 1장에서 계층형 아키텍처에 대한 불만을 이야기했으니 이번 장에서는 단일 책임 원칙과 의존성 역전 원칙 이야기로 시작해보자~ 단일 책임 원칙 「 이 원칙의 일반적인 해석 」 "하나의 컴포넌트는 오로지 한 가지 일만 해야 하고, 그것을 올바르게 수행해야 한다" 하지만, 단일 책임 원칙의 실제 의도는 아니다 '오로지 한 가지 일만 하는 것’은 단일 책임이라는 말을 직관적으로 해석한 것 단일 책임 원칙이라는 이름에 오해의 여지가 있다 단일 책임 원칙의 실제 정의 「 이 원칙의 실제적인 정의 」 ＂컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다" “단일 책임 원칙” '책임'은 사실' 오로지 한 가지 일만 하는 것'보다는 '변경할 ..

2022. 12. 22. 19:40

도서 요약

[만들면서 배우는 클린 아키텍처] 1. 계층형 아키텍처란?

"만들면서 배우는 클린 아키텍처" 도서를 정리한 내용입니다. 1. 계층형 아키텍처의 문제는 무엇일까? 계층형 아키텍처 “잘 만들어진 계층형 아키텍처는 변화하는 요구사항과 외부 요인에 빠르게 적응할 수 있게 한다” 계층형 아키텍처는 데이터베이스 주도 설계를 유도한다 하지만, 우리가 만드는 애플리케이션의 목적을 생각해보자 애플리케이션을 만드는 목적이 뭘까? "비즈니스 규칙이나 정책"을 반영한 모델을 더욱 편리하게 활용해야 하지 않을까? "상태보다 행동"을 중심으로 모델링 해야 하지 않을까? 그럼 왜 "도메인 로직"이 아닌 "데이터베이스"를 토대로 아키텍처를 만드는 걸까? 여러분들의 애플리케이션 유스케이스 여러분들이 이전에 만든 애플리케이션의 유스케이스를 한번 생각해보라~ "도메인 로직"을 먼저 구현했는가? ..

2022. 12. 22. 19:34