CS

비교에 앞서 간단한 개념 설명 DTO : 순수하게 데이터 전달만을 위한 개체 getter/setter 메소드 말고 다른 로직은 없다. 가변성이 있지만 setter 메소드를 제거하고 대신 생성자로 필드에 데이터를 넣으면 불변성을 갖는다. ( 개인적으로 setter 메소드를 제거한 DTO는 반쪽짜리 VO라고 해도 무방한 것 같다. 딱 VO에서 euals(),hashCode() 만 오버라이드만 안한 상태? ) 보통 변화에 민감하지 않는 , 값을 비교할 필요 없는 데이터를 이동시킬 때 사용한다. VO : 값 그 자체를 나타내는 객체 데이터의 변화가 없는 불변성을 갖는다.( setter 메소드 사용하지 않는다. ) 서로 다른 VO여도 갖고 있는 데이터가 같으면 같은 객체라고 정의한다.(그림2 참고) , 이를 위해..

URI(Uniform Resource Identifier)란? 직역하면 "통합 자원 식별자" 라고 하는데 처음에는 이해하기 어렵다. 좀 더 쉽게 표현하면 인턴넷 어딘가에 있는 자원을 찾아 식별하는 문자열 형식이다. 그럼 URL(Uniform Resource Locator)란? 흔히 웹 주소라고도 하는데 , 인터넷 어딘가에 있는 자원의 위치를 표현하는 문자열 형식이다. 읽어보면서 느낄 수 있듯이 URL은 URI의 서브셋(부분집합)이다. 따라서 모든 URL은 URI 이다. 그럼 두 개념을 구분하는 건 무엇이냐? 그건 URI는 식별하고 , URL은 위치를 가르킨다는 것이다. 즉 URL은 식별자가 필요 없는 좀 더 작은 개념인 셈이다. 예시를 보면 좀더 이해하기 쉽다. https://forrest-code-13..

REST API 전에 REST란 무엇인지에 대해 먼저 알아볼 필요가 있다. 만들어진 계기 REST(REpresentational State Transfer)는 HTTP(웹)의 주요 저자 중 한 사람인 로이 필딩이라는 사람이 만들었는데 자기가 봐도 너무 잘 만든 HTTP를 사라들이 사용을 안하니까 제발 좀 사용하라고 보조기구?처럼 만든 HTTP 의 장점을 최대로 활용할 수 있는 아키텍처다. 정의 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태/정보를 주고받는 모든 것을 의미한다. 즉 자원(resource)의 표현(representation)을 기반으로 한 상태(정보)전달을 의미한다. 구체적으로는 HTTP URI를 통해 자원을 명시하고 , HTTP Method를 통해 해당 자원에 대한 CRUD를 적..

@Component : 개발자가 직접 만든 Class를 spring Bean으로 등록하기 위한 Annotation이다. 스프링은 이거 보고 spring bean으로 등록한다. @ComponentScan : @Component, @Service, @Repository, @Controller, @Configuration 중 1개라도 붙어있는 클래스를 찾으면 context에 bean으로 등록한다.또한 @Component Annotation이 있는 클래스들은 bean인스턴스를 생성해준다. @Bean : @Bean Annotation은 개발자가 제어가 불가능한 외부 라이브러리 같은 것들을 Bean으로 만들 때 사용한다. @Controller : Spring에게 해당 Class가 Controller의 역할을 한다고..

HTTP method를 설명하기 위해서는 HTTP가 무엇인지 부터 알아야 한다. 간단하게 설명하면 인터넷에서 데이터를 주고받을 수 있는 프로토콜(규칙)이며 아래와 같은 순서로 동작한다. 클라이언트 측에서 브라우저를 통해 어떤 서비스를 url을 통해 또는 다른 것을 통해 ( 대부분 url ) 요청(request)을 하면 서버에서는 해당 요청에 맞는 결과값을 클라이언트에게 응답(response)의 형태로 돌려준다. HTTP 를 통해 HTML , JSON , XML 등과 같은 형태의 정보를 주고받을 수 있다. 보통 클라이언트가 어떤 형태의 정보를 받고싶다고 명시해주는 경우가 많다. 그럼 HTTP method란? 위에서 설명한 요청(request)과 응답(response)의 방식 , 쉽게는 서버에 요청보내는 방..

Controller 란? 사용자의 요청이 들어오면 응답을 해주기 위해 Service를 호출 , Service에서 실질적으로 처리한 내용,결과물을 다시 받아서 사용자에게 전달(보통 View에 전달해서 사용자가 눈으로 볼 수 있게 해준다.)해주는 역할을 하는 것 Service 란? Controller에서 사용자의 요청을 처리하기 위해 호출하는 것으로 , Service는 알맞은 정보를 가공,처리하여 Controller에게 데이터를 넘긴다.이 때 알맞은 정보를 가공,처리하기 위한 비즈니스 로직을 수행하며 , 가공,처리하는 과정에서 필요한 데이터는 Repository를 호출해 전달받는다. Repository란? Entity에 의해 생성된 DB에 접근하는 메서드 들을 사용하기 위한 인터페이스로 , 쉽게 말해 DB와..

흔히 service에서 비즈니스 로직을 수행한다고들 한다. 그럼 service에서 하는 일을 정리하면 그게 비즈니스 로직이지 않을까? 라는 생각으로 비즈니스 로직을 정의 하고 싶다. 일단 service는 controller에서 사용자의 요청을 받아서 실제 데이터를 가공해서 요청에 맞는 응답을 controller에게 다시 전해준다. 위 문장을 정리해서 비즈니스로직을 정의해 보면 ,비즈니스 로직은 사용자의 요청에 맞게 프로그램에서 데이터를 생성,처리,가공,저장하는 일 , 좀 더 쉽게는 사용자가 원하는 기능을 수행해주기 위해 구현하는 로직 이라고 할 수 있다.

Domain이란? 개념적으로는 '영역'을 말한며 , 소프트웨어로 구현하고자 하는 문제 영역이라고 할 수 있다. 맛집 공유 애플리케이션을 예를 들면 맛집 정보를 저장하는 회원 맛집으로 저장되는 음식점 자신의 맛집을 다른 회원과 공유하는 과정 이들을 가각의 도메인 이라고 부를 수 있다. DDD( Domain Driven Design ) 만들어진 계기는 일방향적인 소통과 개발에서 출발한다. 도메인 전문가들이 도메인을 추상화해서 모델을 추출,설계한다. 개발자들은 모델만을 보고 소프트웨어를 실체화한다. 위 과정에서의 문제점은 도메인 전문가들은 개발자들을 생각하지 않고 복잡하게 도메인을 짠다 -> 소프트웨어의 복잡성 높아진다. 개발자들은 모델을 만든 도메인 전문가들의 의도를 모른 상태로 소프트웨어를 만든다 -> 도..