일상_자기계발

해당 글은 인프런 김영한 강사님의 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 을 보고 정리한 내용입니다. 자바 실행 자바의 main 메서드를 실행하는 경우 main 이라는 이름의 쓰레드가 실행된다. 에러가 발생하고 잡지 못하면 main 쓰레드가 예외 정보를 남기고 종료된다. 웹 애플리케이션 사용자 요청 별로 별도의 쓰레드가 할당 되고, 서블릿 컨테이너 안에서 실행된다. try ~ catch로 예외를 잡으면 아무런 문제가 없지만 잡지 못하고 서블릿 밖으로 전달되면 서블릿의 오류 페이지 요청 흐름 WAS → 필터 → 서블릿 → 인터셉터 → 컨트롤러 ⇒ 정상요청 WAS ← 필터 ← 서블릿 ← 인터셉터 ← 컨트롤러(예외발생) ⇒ 예외발생 WAS “/error-page/500" → 필터 → 서블릿 → 인터..

해당 내용은 AWS에서 작성 된 글을 참고 했고 저의 생각을 정리했기 때문에 참고 부탁드리겠습니다. API가 무엇일까? 다른 소프트웨어 시스템과 통신하기 위한 규칙을 정하게 되는데 이를 API로 표시하는 방법이라고 한다. Interface라는 단어가 있기 때문에 중간에서 서로간의 소통을 하기 위한 표현방법(?)이지 않을까? 이러한 소통을 위해 정보를 주고 받는 이동수단(?)을 HTTP라는 프로토콜을 사용해서 값을 전달한다?라고 이해하고 있다. 웹 리소스라는 단어 찾으면서 특정 블로그 글을 보았는데 http://jm-baek.tistory.com/manage/newpost/?type=post&returnURL=%2Fmanage%2Fposts%2F 현재 블로그 글을 작성하고 있는 URL을 보면 위와 같이 [..

스프링에서 자주 사용하는 어노테이션을 생각 나는대로 적어보자~! @Controller: 컨트롤러 계층 등록 @RestController: 컨트롤러에서 View가 아닌 Json 형태로 객체를 반환할 때 @Service: 서비스 계층 등록 @Component: 내부적으로 자주 사용하는 메소드를 작성 할 때(?) @Configuration: 외부 라이브러리를 빈으로 등록 할 때(?) @Override: 인터페이스에서 작성한 메소드를 서비스에서 정의하기 위해 사용할 때 @Autowired: 객체 의존성 주입을 할 때~! @RequestBody: 요청 데이터를 Request 객체가 아닌 VO나 MAP 등으로 매핑할 때? @Data: LOMBOK의 어노테이션으로 @Getter / @Setter, @ToString,..

세 개 레이어(controller, service, repository)가 DDD에 맞는 설계인지 방금알았따~! 뚜뚠. 각 계층마다 역할이 있는데 코드를 작성할 때면 controller, service 어디에서 처리하는게 좋을지 헷갈리는 경우가 가끔있다. 즉, 어느 범위까지 해당 계층이 처리해줬으면 하는 역할을 줘야하는지 실력(짬?)이 안되다 보니까 코드 마다 일관적이지 않는 부분이 있다. Service 계층에서 처리해야 되지 않을까 하는 부분을 Controller에서 처리하도록 한 적이 꽤 많다.(데헷) controller 클라이언트로부터 요청(Request)를 받고 서비스 계층으로 요청을 보내고 받은 처리된 결과를 반환하는 계층이다. service 비즈니스 로직 처리를 하는 계층으로 controlle..

제대로 이해를 못했기 때문에 해당 내용을 경계하며 읽어주셨으면 감사하겠습니다. 💥 Chat GPT가 알려준 예시이다. 주문 관리 시스템을 만든다고 가정해봅시다. SQL 중심 설계에서는 주문 데이터베이스 테이블이 존재하고, 이 테이블과 주문 상세 테이블, 상품 테이블, 회원 테이블 등이 서로 관계를 맺습니다. 따라서 데이터베이스 테이블 간의 관계가 중심이 되며, 비즈니스 로직은 데이터베이스 스키마에 맞게 설계됩니다. DDD 설계에서는 주문, 주문 상세, 상품, 회원 등의 도메인 개념이 중심이 됩니다. 예를 들어, 주문 도메인에서는 주문 생성, 주문 취소, 결제 처리 등의 비즈니스 로직이 포함됩니다. 이러한 비즈니스 로직을 기반으로 주문 도메인 객체가 설계되며, 데이터베이스 스키마는 이를 지원하기 위해 구성..

내용이 틀릴 수 있기 때문에 경계하며 읽어주셨으면 좋겠습니다. 블로그 글을 보면 vo, entity, dto에서 더 나아가면 도메인 설계에 대해서도 언급이 된다고하는데 아직 어떻게 연관이 있는지 잘 모르겠다. 추후 이해가 된다면 해당 글을 수정할 수 있도록 하겠다. VO(Value Object) 메모리 주소가 다르지만(?) 해당 객체의 값이 같다면 같은 객체로 취급한다. 이를 위해서 eqauls와 hashmethod를 재정의하는 것 같다...!(아닐 수도 있다.) 그리고 값을 변경(setter)하면 안된다. 따로 메소드(로직)을 가져된다, DTO(Data Transfer Object) 계층 간의 데이터를 전송하는 객체라고 생각한다. 따라서, setter를 사용해도 괜찮지만 따로 메소드(로직)을 가져서는 ..