알쏭달쏭 컴퓨터 세상

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

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

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

1. 스프링 AOP 비즈니스 컴포넌트 개발에서 가장 중요한 두 가지 원칙은 낮은 결합도와 높은 응집도 스프링의 의존성 주입을 이용하면 비즈니스 컴포넌트를 구성하는 객체들의 결합도를 떨어뜨릴 수 있어서 의존관계를 쉽게 변경 가능 IoC - 결합도 vs. AOP - 응집도 AOP 이해하기 AOP(Aspect Oriented Programming)은 예외, 트랜잭션 등의 부가적인 코드들을 효율적으로 관리하는 데 주목 관심 분리(Separation of Concerns) 횡단 관심 : 메소드마다 공통으로 등장하는 로깅, 예외, 트랜잭션 처리 등의 코드 핵심 관심 : 사용자 요청에 따라 실제로 수행되는 핵심 비즈니스 로직 두 관심을 완벽하게 분리할 수 있다면 간결하고 응집도 높은 코드 유지 가능. 하지만 독립적인..

1. 개발 환경 구축 JDK 설치 -> 이클립스 EE 설치 -> tomcat 서버 설치 및 연동 -> 데이터베이스 구축(h2) -> STS(Spring Tool Suite) 플러그인 설치 2. 프레임워크 개요 프레임워크 개념 "뼈대 혹은 틀". 아키텍처에 해당하는 골격 코드 제공. 개발자에게 모든 것을 위임하지 않고, 애플리케이션의 기본 아키텍처는 프레임워크가 제공하고 그 뼈대에 살을 붙이는 작업만 개발자가. 장점 빠른 구현 시간 : 개발자는 비즈니스 로직만 구현하면 됨 쉬운 관리 : 같은 프레임워크 적용된 App은 아키텍처 같아서 관리 쉬움. 유지보수도 효율적. 개발자들의 역량 획일화 : 숙련자/초심자의 차이가 적음. 개발 인력 효율적 구성 가능. 검증된 아키텍처의 재사용과 일관성 유지 : 별다른 검증..