Back-End35 Spring 네이버 클로바 OCR 연결 프론트엔드에서는 보안이 보장된 HTTPS를 통해 네이버 클로바 OCR API로 요청을 보내지 못하기 때문에 HTTPS로 보안 접속이 가능한 백엔드에서 CLOVA OCR API로 요청을 보내도록 구현해야 했다. 백엔드는 스프링 프레임워크에서 구현했다. 이 글에서는 CLOVA OCR 도메인 등록 이후 백엔드에서 OCR API에 요청을 보내고 반환 받은 텍스트 인식 결과를 이용하는 기능을 구현하기 위해 백엔드와 OCR API를 연결하는 방법을 작성하려 한다. 여기서는 CLOVA OCR의 일반 모델이 아닌 영수증 특화 모델을 이용했다. (모델에 따라 버전이 상이하기 때문에 참고해야 하는 API 예제 코드가 다르다.) 코드 작성 우선 application.yml 파일에 OCR API 관련된 사항을 추가해준다.. 2025. 4. 5. 팀 생성 여부 조회 시 URI 형식 내 질문- URI에서 특히 filter 여러 개를 설정할 때 %의 역할이 뭐야? 예를 들면 https://www.kurly.com/collection-groups/market-best?page=1&collection=market-best-logic&filters=category%3A910%2C911%2C912 여기서 category의 % 같은 거! - 이것처럼 나는 /team/?member= 이런 식으로 member 안에 사용자가 선택하는 여러 명의 사람들의 id를 여러 개 넣고 싶으면 &을 써서 나열해야 돼? 아니면 저 category처럼 %를 써야 돼?- 백엔드는 Spring으로 개발 중이야. 사용자가 사람들을 선택해서 버튼을 눌렀을 때 프론트에서 그 사람들의 memberId들을 URL에 넣어서 백으.. 2025. 2. 15. StringBuilder는 변경 가능한 문자열 참고)[JAVA] StringBuilder란? StringBuilder 사용법[Java] StringBuilder 사용법과 주요 메소드 2024. 5. 14. [DDD] 도메인 주도 개발 시작하기 Ch11 Chapter 11 CQRS11.1 단일 모델의 단점 ∘ 주문 내역 조회 기능을 구현하려면 여러 애그리거트에서 데이터를 가져와야 됨 ∘ 조회 기능을 구현할 때 식별자를 이용해서 애그리거트를 참조하면 즉시 로딩과 같은 JPA의 쿼리 관련 최적화 기능을 사용할 수 없음. 직접 참조하더라도 조회 화면 특성에 따라 같은 연관도 즉시 로딩이나 지연 로딩으로 처리해야 되므로 고민해야 됨. ∘ 이러한 문제는 시스템 상태를 변경할 때와 조회할 때 단일 도메인 모델을 사용하기 때문 ∘ 이런 상황에서 구현 복잡도를 낮추려면 상태 변경을 위한 모델과 조회를 위한 모델을 분리하면 됨 11.2 CQRS ∘ 시스템이 제공하는 기능 : 상태를 변경하는 기능, 사용자 입장에서 상태 정보를 조회하는 기능 ∘ 도메인 모델 관점에서 상태.. 2024. 4. 29. [DDD] 도메인 주도 개발 시작하기 Ch10 Chapter 10 이벤트10.1 시스템 간 강결합 문제∘ 외부 시스템의 서비스를 호출할 때의 문제 - 외부 서비스가 정상이 아닐 때 트랜잭션 처리가 애매함 - 트랜잭션을 롤백할지 말지 - 외부 서비스의 성능에 직접적인 영향을 받음 - 설계상 서로 다른 로직이 섞일 수 있음 ∘ 컨텍스트 간의 강결합이 있으면 결합된 컨텍스트끼리 영향을 주고받게 됨 ∘ 이벤트를 사용하면 강결합 제거 가능10.2 이벤트 개요∘ 이벤트 : 과거에 벌어진 어떤 것. 상태가 변경됐음을 의미. ∘ 이벤트가 발생하면 그에 따른 동작이 수행됨 10.2.1 이벤트 관련 구성요소∘ 이벤트 도입을 위해서는 이벤트, 이벤트 생성 주체, 이벤트 디스패처(퍼블리셔), 이벤트 핸들러(구독자)를 구현해야 됨 - 이벤트 생성 주체 : 엔티.. 2024. 4. 29. [DDD] 도메인 주도 개발 시작하기 Ch9 Chapter 9 도메인 모델과 바운디드 컨텍스트 9.1 도메인 모델과 경계 ∘ 한 개의 모델로 여러 하위 도메인을 모두 표현하려 하면 안 됨 ex. 재고 관리에서의 상품, 주문에서의 상품, 배송에서의 상품에서 상품은 다 다른 의미를 가짐 ∘ 하위 도메인마다 사용하는 용어가 다르기 때문에 올바른 도메인 모델을 개발하려면 하위 도메인마다 모델을 만들어야 함 ∘ Bounded Context : 모델이 완전한 의미를 갖는 경계가 있는 컨텍스트 9.2 바운디드 컨텍스트 ∘ 바운디드 컨텍스트는 모델의 경계를 결정함 ∘ 한 개의 바운디드 컨텍스트는 논리적으로 한 개의 모델을 가짐 ∘ 바운디드 컨텍스트는 실제로 사용자에게 기능을 제공하는 물리적 시스템 ∘ 여러 하위 도메인을 한 개의 바운디드 컨텍스트에서 개발할 때는.. 2024. 4. 8. [DDD] 도메인 주도 개발 시작하기 Ch8 Chapter 8 애그리거트 트랜잭션 관리 8.1 애그리거트와 트랜잭션 ∘ 운영자는 상품의 배송 상태를 바꾸고, 동시에 고객은 배송지 정보를 바꿈. 서로 다른 애그리거트 객체를 이용하지만 트랜잭션 커밋할 때 두 정보가 다 바뀜 → 애그리거트의 일관성이 깨짐 ∘ 애그리거트 트랜잭션 처리 방식에는 선점 잠금과 비선점 잠금이 있음 8.2 선점 잠금 ∘ 선점 잠금 : 먼저 애그리거트를 구한 스레드가 애그리거트 사용이 끝날 때까지 다른 스레드가 해당 애그리거트를 수정하지 못하게 블로킹 ∘ 먼저 애그리거트를 사용하던 스레드가 수행하고 트랜잭션을 커밋하면 잠금이 해제됨 ∘ 데이터 충돌 문제 해결 가능 ∘ 선점 잠금은 보통 DBMS가 제공하는 행단위 잠금을 사용해서 구현 ∘ JPA 프로바이더와 DBMS에 따라 잠금 모.. 2024. 4. 1. [DDD] 도메인 주도 개발 시작하기 Ch7 Chapter 7 도메인 서비스 7.1 여러 애그리거트가 필요한 기능 ∘ 여러 개의 애그리거트가 필요한 경우가 있음 ex. 결제 금액 계산 로직의 경우 상품, 주문, 할인 쿠폰, 회원 애그리거트가 필요함 ∘ 복잡하다고 기능과 관련 없는 구성 요소가 있는 애그리거트에 기능을 넣으면 안 됨 ∘ 애그리거트가 자신의 책임 범위를 넘어서는 기능을 구현하게 되면 외부에 대한 의존이 높아지고 코드 수정이 어려워짐 ∘ 애그리거트가 여러 개 있을 때 기능을 어디에 구현할지에 대한 문제가 생기면 도메인 기능을 별도 서비스로 구현하면 됨 7.2 도메인 서비스 ∘ 도메인 서비스는 도메인 영역에 위치한 도메인 로직을 표현할 때 사용 7.2.1 계산 로직과 도메인 서비스 ∘ 특정 애그리거트에 넣기 어려운 도메인 개념은 도메인 서.. 2024. 4. 1. 이전 1 2 3 4 5 다음
