어떤 관심사들이 있을까? 프로그램에는 다음과 같은 관심사들이 보통 존재한다. 1. 뷰를 그리기 위한 렌더링 로직 2. 비즈니스 로직 3. 네트워크 요청 이런 관심사에 따라 크게 세가지 레이어로 나누었다. 1. Domain layer: Entity, Repository Interface, Use Case 2. Data layer: Repository Impl, Data Source 3. Presentation layer: 리액트 코드 Domain layer 도메인 레이어에는 엔티티가 존재했다. 추구했던 방향은 Class로 entity를 나타내고 해당 entity에서 수행해야 하는 비즈니스 로직을 메서드로 표현하고 싶었다. 하지만 2가지 문제점이 있었다. 1. 앱 자체가 어찌보면 단순한 CRUD 앱이었기 때..

아키텍쳐 코드스쿼드에서 팀 프로젝트를 진행하면서 처음 사용했던 리액트. 팀 프로젝트 당시엔 데모도 해야하고 백엔드가 제공해준 API를 화면에 그리지 못하면 민폐라 생각해 마구잡이로 컴포넌트를 짜고 어떻게든 화면만 그렸었다. 하지만 항상 마음 속에 무언가 찜찜함이 있었다. 이렇게 지저분한 코드로 어떻게든 화면만 그려내는건 내가 원했던 개발자로서의 모습이 아니었다. 리액트를 처음 배운다는, 팀원들에게 화면을 보여줘야 한다는 핑계 뒤에 숨어 마구잡이로 컴포넌트를 짜고 있다가 문득 이런 생각이 들었다. 지금 내가 하는 프로젝트가 그렇게 큰 프로젝트도 아닌 것 같은데, 만약 회사에서 더 큰 프로젝트를 만들 때 내가 수많은 수정사항들을 다 처리할 수 있을까? 주어진 피그마대로 화면을 그리는건 쉽다. 하지만 내가 걱..

useQuery의 반환값들 크게 두 범주로 생각할 수 있는데, 캐쉬된 데이터의 상태와 데이터 페칭에 대한 상태로 생각하면 쉽다. 데이터에 대한 상태값 - status === ‘pending’ 쿼리에 데이터가 없을 경우 isPending - status === 'error' 쿼리에 오류가 생긴 경우 isError - status === 'success' 쿼리가 성공적이었고 데이터가 사용 가능한 경우 isSuccess 페칭 상태에 대한 값 - fetchStatus === 'fetching' - 쿼리가 페칭 중일때 - fetchStatus === 'paused' - 쿼리는 페치를 하고 싶지만, 일시중지 됐을때. - fetchStatus === '..

개요 파사드는 라이브러리, 프레임워크 또는 기타 복잡한 클래스 집합에 단순화된 인터페이스를 제공하는 디자인 패턴이다. 해결하려는 문제 정교한 라이브러리나 프레임워크의 다양한 객체들을 다룰 때 모든 객체를 초기화하고, 종속성을 추적하고, 메서드를 올바른 순서로 실행하는 등의 작업을 수행해야 한다. 결과적으로 클래스의 비즈니스 로직이 써드 파티 라이브러리의 구현 세부 사항과 긴밀하게 결합되어 유지 관리가 어려워지게 된다. 해결법 파사드는 복잡한 서브시스템에 간단한 인터페이스를 제공하는 클래스다. 파사드는 서브시스템을 직접 사용하는 것보다 제한된 기능을 제공할 수 있다. 하지만 클라이언트가 실제로 중요하게 생각하는 기능만 포함한다. 파사드는 수십 개의 기능이 포함된 정교한 라이브러리와 앱을 통합해야 하지만 일..

6장 아키텍처를 고려할 때 변수의 가변성을 염려할까? 대답은 단순하다. 경합race 조건, 동시 업데이트concurrent update 문제가 모두 가변 변수로 인해 발생하기 때문이다. 다시 말해 우리가 동시성 애플리케이션에서 마주치는 모든 문제, 즉 다수의 스레드와 프로세스를 사용하는 애플리케이션에서 마주치는 모든 문제는 가변 변수가 없다면 절대로 생기지 않는다. 변수를 변경하는 컴포넌트와 변경하지 않는 컴포넌트를 분리해야 한다. 이렇게 분리하려면 가변 변수들을 보호하는 적절한 수단을 동원해 뒷받침해야 한다. 현명한 아키텍트라면 가능한 한 많은 처리를 불변 컴포넌트로 옮겨야 하고, 가변 컴포넌트에서는 가능한 한 많은 코드를 빼내야 한다. 이벤트 소싱 계좌 잔고를 변경하는 대신 트랜잭션 자체를 저장한다고..

1장 설계 design와 아키텍쳐 사이에는 어떤 차이가 있을까? 아무런 차이가 없다. 아키텍처는 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬 때 흔히 사용된다. 설계는 저수준의 구조 또는 결정사항 등을 의미할 때가 많다. 설계의 목표는? 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는 데 있다. 2장 모든 소프트웨어 시스템은 이해관계자에게 서로 다른 두 가지 가치를 제공한다. 행위와 구조가 바로 그것이다. 대부분의 프로그래머는 행위(시스템이 동작하도록 하는 것)가 자신이 해야 할 일의 전부라고 생각한다. 소프트웨어라는 단어는 부드러운soft과 제품ware이라는 단어의 합성어이다. 제품이라는 단어는 상품product를 뜻하며, 부드러운soft이라는 단어는 행위를 쉽게 변경할 수 ..