Category Java

헥사고날 아키텍처의 포트는 엔티티가 아니라 의도로 나눈다

Member 엔티티가 있으니 MemberService 하나, MemberController 하나. 스프링을 배우면 대부분 이 구조로 시작한다. 처음에는 편하다. 문제는 N개월 뒤에 온다. MemberService는 메서드 열다섯 개짜리 클래스가 되고, 그것을 주입받은 코드만 봐서는 무슨 목적으로 쓰는지 알 수 없다. 헥사고날 아키텍처는 이 지점에서 다른…

도메인 값 객체와 요청 DTO를 분리한 트레이드오프

MemberRegisterRequest 같은 요청 오브젝트를 어느 계층에 둘지 물으면, 개발자가 반사적으로 “애플리케이션 레이어”라고 답한다. DTO는 데이터를 담아 계층 경계를 넘기는 역할이니 서비스 레이어에 두는 것이 자연스럽다는 이유다. 그런데 헥사고날 아키텍처로 회원 등록 기능을 만들 때, 이 오브젝트를 도메인 레이어에 두었다. 결론부터…

Java로 HTTP 서버 개선기 — 리플렉션 서블릿으로 매핑 자동화하기

기존 커맨드 패턴의 한계 이전 버전(V5)에서는 커맨드 패턴 기반의 서블릿을 사용했다. 각 URL 경로마다 별도의 서블릿 클래스를 만들고, 이를 ServletManager에 일일이 등록해야 했다 이 방식에는 두 가지 명확한 단점이 있다 기능이 수십 개로 늘어난다면? 클래스 파일과 매핑 코드가 함께 폭발적으로…

리플렉션(Reflection)

리플렉션이 필요한 이유 커맨드 패턴으로 서블릿을 구현할 때 흔히 부딪히는 두 가지 불편함이 있다 기능 하나당 클래스 하나 – 클래스가 폭발적으로 늘어난다 반면 아래처럼 하나의 컨트롤러에 여러 기능을 모을 수 있다면 훨씬 깔끔해진다 URL 경로 /site1이 들어오면 site1() 메서드를 이름으로…

Java로 HTTP 서버 만들기 — 커맨드 패턴으로 서버와 비즈니스 로직 분리하기

왜 분리가 필요한가? 이전 버전의 HttpRequestHandler를 보면 문제가 바로 보인다 home(), site1(), site2(), search() 같은 서비스 로직이 서버 코드 안에 직접 박혀 있다. 다른 프로젝트에서 이 서버를 재사용하려면? 이 로직들을 전부 갈아엎어야 한다. 재사용이 불가능하다. 해결책은 명확하다. 서버가 해야 할…

Java로 HTTP 서버 만들기 — 요청과 응답을 객체로 구조화하기

왜 객체로 만드는가 HTTP 메시지는 명확한 규칙을 가진다 이 규칙이 존재한다는 것은 구조화할 수 있다는 의미다. 문자열을 매번 직접 파싱하는 대신, HttpRequest, HttpResponse 객체로 캡슐화하면 코드의 복잡도가 극적으로 줄어든다 HttpRequest – 요청 파싱 생성자에서 BufferedReader를 받아 시작 라인 → 헤더…

Java로 HTTP 서버 만들기 — 스레드 풀로 동시 요청 처리

1편에서 만든 HttpServerV1은 요청을 순차적으로 처리했다. 첫 번째 요청이 5초 걸리면 두 번째 요청은 5초를 기다려야 했다. 실제 서비스라면 절대 용납할 수 없는 구조다. 해법은 단순하다. 요청마다 별도의 스레드를 할당하면 된다 구조 변경 V1의 구조는 메인 스레드가 연결 수락과 요청…

Java로 HTTP 서버 만들기 — 소켓 위에 HTTP 올리기

HTTP는 결국 TCP 위에서 동작하는 텍스트 프로토콜이다. 즉 다음과 같은 흐름이다 소켓을 열고, 텍스트를 읽고, HTTP 규약에 맞춰 응답을 쓰면 된다 HTTPServerV1 서버를 실행한 후 브라우저에서 http://localhost:12345에 접속하면 된다 설계 포인트 BufferedReader와 PrintWriter를 선택한 이유 HTTP는 텍스트 기반 프로토콜이다. 바이트…

Java 채팅 프로그램 서버 구현 — Null Object 패턴

3편에서 커맨드 패턴을 도입해 명령어마다 독립적인 클래스를 만들었다. 그런데 CommandManagerV3의 execute()를 보면 아직 한 가지 거슬리는 부분이 남아 있다 명령어를 찾고, null이면 처리하고, 아니면 실행한다. 로직 자체는 맞지만 null 체크가 흐름을 끊는다. 이상적인 코드는 이렇다 명령어를 찾고, 바로 실행한다. 이…