본문으로 건너뛰기

6개 문서가 "Software Design" 태그에 분류되었습니다

모든 태그 보기

DB 조회는 왜 아웃바운드일까요?

인바운드/아웃바운드 어댑터를 가르는 기준은 데이터의 방향이 아니라 호출의 방향입니다. 이벤트 리스너와 fetch, props 콜백에 대응시켜 의존성 규칙과 의존성 역전(DIP)까지 풀어봅니다.

그 로직은 어디에 살아야 할까요?

검증 로직 하나를 두고 모델·서비스·컨트롤러 사이에서 고민해 본 경험으로 풀어보는 로직의 자리 — rich/anemic 도메인 모델의 스펙트럼, 도메인 서비스와 애플리케이션 서비스의 구분, 그리고 권한이 사는 곳.

도메인 모델은 왜 DB를 몰라야 할까요?

헥사고날 아키텍처가 모델을 중심에 놓는 이유를 프론트엔드 개발자의 언어로 풀어봅니다. React 코어와 렌더러의 관계로 이해하는 포트와 어댑터, 그리고 요청 하나가 레이어를 지나가는 길.

무엇을 상태로 두지 말아야 할까요?

리액트에서 매일 만나는 세 가지 질문 — 이 값은 화면을 다시 그려야 하나, 이 값은 계산되는 값인가, 이 흐름은 상태 변화를 관찰해서 이어지나. 최신 값 참조·파생 상태·절차 실행이라는 세 원칙을 상태를 줄인다는 하나의 관점으로 묶어 풀어봅니다.

이 응답은 누구 것인가요?

요청과 응답의 짝은 HTTP 스택이 대신 맞춰줍니다. SSE, WebSocket, postMessage처럼 채널 하나에 메시지가 여러 개 흐르면 그 장치가 사라집니다. 상관키 대신 동시성을 1로 낮출 때 무엇이 부채로 남는지 실행 예제로 확인합니다.

타입스크립트로 잘못된 상태 막기

런타임에 터지는 버그의 상당수는 타입이 그 상태를 허용했기 때문에 생깁니다. 태그 유니온·브랜디드 타입·parse don't validate 세 축으로 잘못된 상태를 컴파일 단계에서 봉쇄하는 법을 정리합니다.