알쏭달쏭 컴퓨터 세상

본 책에서 다루는 예제를 바탕으로 하고 있습니다. 계층으로 구성하기 인터페이스 & 인터페이스 구현체 → 최적은 아님… 문제점 : functional slice나 feature를 구분 짓는 패키지 경계가 없다. 애플리케이션이 어떤 유스케이스들을 제공하는지 파악 불가 기능으로 구성하기 상위 패키지 안에 다 때려넣기 장점 : 패키지 경기를 package-private 접근 수준과 결합하면 기능 사이의 불필요한 의존성 방지 가능 AccountService의 책임을 좁히기 위해 SendMoneyService. → 기능과 의도를 소리치고 있음! 단점 : 가시성 떨어짐 의존성 역전을 시켰지만, 도메인 코드가 실수로 영속성 코드에 의존하는 것을 막을 수 없다. 아키텍처적으로 표현력 있는 패키지 구조 adapter 애플..

단일 책임 원칙(SRP) ‘책임’ → ‘변경할 이유’ 로 해석이 더 맞을 듯 “컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다” 어떤 다른 이유로 sw를 변경하더라도 이 컴포넌트에 대해서는 전혀 신경 쓸 필요 없다. 변경돼도 우리가 기대한 대로 동작할 것 의존성 역전 원칙(DIP) 계층형 아키텍처에서 항상 의존성은 아래를 향하므로, 상위 계층들이 하위 계층보다 변경할 이유가 더 많다. (영속성 계층을 변경할 때마다 도메인도 변경해야 함) “코드상의 어떤 의존성이든 그 방향을 역전시킬 수 있다” 의존성의 양쪽 코드를 모두 제어할 수 있을 때만 의존성 역전 가능. 도메인 객체를 표현하는 엔티티부터 도메인 계층으로 올린다 영속성 계층에 있는 Repository가 엔티티에 의존하므로 ‘순환 의존성’ 발생 → ..

기술 서적은 기록을 해두지 않으면 금방 잊어버리는 것 같다... 필요한 내용을 찾을 때 뭔가 관련된 부분이 있었는데 하는 생각은 들지만 바로 찾아내기는 어려울 때도 많아서, 아무튼 내용 정리의 중요성을 느끼고 진짜 간단하게 작성하는 글. 계층형 아키텍처는 데이터베이스 주도 설계를 유도한다. 전통적인 계층형 아키텍처의 토대 = 데이터베이스 앱을 만드는 목적은 state가 아니라 behavior! 그런데 우리는 늘 db를 먼저 생각해왔다. → orm을 쓰기 때문 orm에 의해 관리되는 엔티티는 영속성 계층. 계층은 아래 방향으로만 접근 가능하므로 도메인과 강한 결합이 생긴다. 지름길 모드 점점 쉽게 접근할 수 있는 지름길 모드를 추구하게 되어 영속성 계층이 비대해질 것… 테스트 어려움 엔티티의 필드를 하나만..