Go Gradually - Repository

1. RESTful API의 개념 및 설계 원칙RESTful API는 클라이언트와 서버 간의 역할을 명확히 분리하여 각 구성 요소가 독립적으로 발전할 수 있도록 설계된 아키텍처이다. 다음의 원칙들이 핵심이다.클라이언트-서버 구조클라이언트와 서버가 서로의 구현에 영향을 받지 않고 독립적으로 변경될 수 있도록 역할을 분리한다.무상태성(Stateless)서버는 클라이언트의 상태를 저장하지 않으며, 각 요청은 독립적으로 처리된다. 실제 개발 환경에서는 세션 등을 사용해 상태를 관리하기도 하지만, REST의 기본 원칙은 무상태를 유지하는 것이다.캐시 처리 가능(Cacheable)응답 데이터는 캐시될 수 있어, 네트워크 부하를 줄이고 성능을 개선할 수 있다.일관된 인터페이스(Uniform Interface)클라이언..

1. 관계형 데이터베이스의 정규화정규화는 데이터베이스 설계 시 데이터 중복을 최소화하고 삽입, 수정, 삭제 이상 현상을 제거하며 데이터 무결성을 유지하기 위한 일련의 과정이다. 정규화 과정을 통해 저장 공간을 효율적으로 사용하고, 일관된 데이터 관리를 보장할 수 있다.정규화의 장점데이터 중복 최소화: 동일 데이터의 반복 저장을 피하여 저장 공간을 절약한다.이상 현상 제거:삽입 이상, 수정 이상, 삭제 이상을 방지한다.데이터 무결성 유지: 데이터의 정확성과 일관성을 보장한다.저장 공간 효율적 사용: 불필요한 중복 저장을 제거하여 공간을 절약한다.정규화의 단점JOIN 연산 필요: 여러 테이블로 분리된 데이터를 조회할 때 복잡한 JOIN 연산이 필요해 성능 저하의 원인이 될 수 있다.2. 비정규화비정규화는 정..

1. 빅뱅 방식빅뱅 방식은 전체 시스템을 한 번에 전면적으로 변경하는 접근 방법이다. 초기 계획에서는 단기간 내에 모든 구성요소를 개편함으로써 빠른 변화를 기대하지만, 실제 적용 단계에서는 여러 가지 문제가 동시에 발생할 가능성이 높다.예시한 팀이 1년간 전면 개편을 목표로 개발에 착수하였다. 초기에는 “1년 동안 열심히 개발하면 모든 것을 한 번에 바꿀 수 있다”는 기대감이 팽배하였다.그러나 실제 적용 단계에 들어서자 “이 방식으로 진행하면 시스템 안정성이 우려된다”는 불안감이 확산되었고, 검증 과정에서 추가 6개월이 소요되었다.배포 단계에서는 마이그레이션 문제로 다시 6개월이 추가되었으며, 최종적으로는 롤백 절차에 1년이 더 소요되는 상황에 이르렀다.결과적으로 원래 계획된 1년이 3년으로 늘어났으나,..

DDD바운디드 컨텍스트 vs 연관관계바운디드 컨텍스트도메인 별 개념의 집합Depth로 표현소유권 개념Aggregate Root 가 최상위 개념하위 모든 리소스를 관리함이대로 RESTful 하게 API 설계 가능연관관계1:1, 1:n, n:1, n:m관계로 표현소유권 개념이 있지만, 바운디드 컨텍스트랑은 별계임도메인 객체 탐색 vs 직접 Repository 조회도메인 객체 탐색도메인 로직 내에서 객체를 자연스럽게 탐색할 때 사용검증, 쓰기 작업 시 사용검증 로직 별로 필요한 애그리거트 루트의 하위 애그리거트 fetch join도메인 로직이 객체지향적으로 상태를 관리할 수 있도록이때만 양방향 연관관계 사용직접 Repository 조회애그리거트 루트에서 객체를 조회할 때 사용단순 읽기 작업 시 사용도메인 객체..

HTTP-WEBWeb : HTML이라는 문서 형태와 HTTP라는 문서 전송 프로토콜, URL로 문서의 위치를 표시하는 시스템HTTP (Hypertext Transfer Protocol)웹에서 데이터를 주고받는 방식 (Server - Client 모델)클라이언트와 서버 사이에서 클라이언트가 메시지(요청, Request)를 주고, 서버가 메시지를 받아서 응답(Response)을 주는 형태의 통신 방법URI(Uniform Resource Identifier)Uniform: 리소스 식별하는 통일된 방식Resource: 자원, URI로 식별할 수 있는 모든 것(제한 없음)Identifier: 다른 항목과 구분하는데 필요한 정보HTML (Hyper Text Markup Language)하이퍼미디어 포맷XML을 바탕..

일급 (”First-class”) 이란?다음과 같은 조건을 만족하는 요소변수에 할당될 수 있음함수의 매개변수로 전달할 수 있음함수의 반환값으로 사용할 수 있음자료구조(배열, 객체 등) 에 저장할 수 있음일급 컬렉션컬렉션 자체를 하나의 클래스로 감싸놓은 것위 “일급 객체”의 “일급”과 다르다.컬렉션 자체에 하나의 “비즈니스적 이름”을 지어줘야 할 때 사용하는 일종의 패턴일급 컬렉션의 구조리스트를 클래스로 감싸놓음List에 대한 직접 접근을 막고, Users 클래스의 메소드로만 List에 접근을 허용하도록 접근을 제어List 내부의 원소에 적용해야 하는 연산에 대해, 지정된 메소드로만 내부 원소들에 연산을 적용하도록 한다일급 컬렉션을 만들어야 하는 이유컬렉션 자체에 비즈니스적 특징이 주어질 때 → 컬렉션에 ..

애플리케이션 개발 순서요구사항 분석뭐가 확장될 것 같은지, 아키텍쳐를 어떻게 설계할지 이 단계에서도 같이 생각 해보기주어져야 하는 메시지를 보고, 어떠어떠한 도메인(객체)가 있는지 생각해보기. → Domain-Driven Design안정적인 구조(확실한 도메인)가 확장성 높은 소프트웨어를 만든다.아키텍처 설계도메인 탐색도메인 별 정의 서술 (Documentation)도메인 별 유스케이스 다이어그램 생성유스케이스별 협력, 책임, 역할 다이어그램화“기능 별”로 필요한 객체 다이어그램 설계 - 해당 기능을 구현하는 데 사용되는 객체들 생성하기다이어그램이 잘 안그려진다면 → 빼먹은 액터는 없는지, 단위기능이 너무 큰건 아닌지 분리해보기필요한 책임에 따른 아키텍쳐 설계도메인의 역할, 책임(기능), 협력(메시지) ..

주의 - 소프트웨어 공학에서 이야기하는 “분석 마비(Analysis Paralysis)” 와 그 해결책으로 나온 애자일 개발 방법론과는 약간 다른 주관적인 관점에서 느낀 내용을 바탕으로 이야기함.현재까지 내가 생각한 소프트웨어 개발의 과정과, 그 모순일반적인 소프트웨어 개발 과정: 설계 → 검증 → 구현검증만 두번 하는 것 같다는 생각을 하게 됨설계를 검증하는 걸 이미 가운데 단계에 했으니구현은 생산적인 결과를 도출하지 않는 무의미한 과정이 되어버림자꾸 좀 더 완벽한 설계만을 찾게 되는 문제 발생.문제점과 그 핵심근데 오만한 생각임. 자료구조를 검증하지 않음.근데 사실 검증하는 타겟 자체가 다름자료구조의 설계 검증 → 구현을 통해서 가능구현력에 따라 자료구조 설계의 검증 결과가 달라짐알고리즘의 논리 검증..

쿠키 개념Name (이름): 쿠키의 고유 식별자입니다.Value (값): 쿠키에 저장되는 실제 데이터입니다.Expires/Max-Age: 쿠키의 유효 기간을 설정합니다.Expires: 정확한 만료 날짜와 시간Max-Age: 쿠키가 유효한 초 단위 시간Domain: 쿠키가 전송될 수 있는 도메인을 지정합니다.set-Cookie 시 앱웹 서버가 직접 지정하여우리 사이트 전용 쿠키라는 것을 지정해둔다.Path: 쿠키가 유효한 서버의 경로를 지정합니다.Secure: HTTPS 연결에서만 쿠키를 전송하도록 합니다.HttpOnly: JavaScript를 통한 쿠키 접근을 방지합니다.SameSite: 크로스 사이트 요청에 대한 쿠키 전송 제어:StrictLaxNoneXSS사용자 브라우저에 스크립트를 실행시켜 정보를 ..