나는현호

요구사항은 유저가 주문을 할수만 있으면 되서 간단하였다. 그러나 구현하면서 몇가지 고민사항이 생겼고 어떻게 해결했는지 서술하겠다. Service와 Repository의 관계 내가 생각하는 MVC 패턴에서의 역할은 다음과 같다. Controller - 엔드포인트의 역할로써 외부의 요청과 응답을 담당한다. Service - 비지니스 로직이 들어가야한다. Entity - 도메인 데이터를 표현하는 층으로, 데이터의 정합성을 보장해줘야한다. Repository - Entity의 물리적인 변화를 담당한다. 또한 Controller -> Service -> Repository 순으로 접근하기에 Service는 Controller를 Repository는 Service의 존재를 몰라야한다. 저번 포스팅에서도 기술했듯이 ..

기본 컨셉은 쇼핑몰이다. 유저가 주문을 하고 확인하는 기능을 만들예정이다. 기본적인 시나리오는 다음과 같다. 1. 유저가 상품을 주문할 수 있다. 2. 주문목록은 여러 목록과 갯수가 있다. ex) 사과 3개, 바나나 2개, 포도 5개 3. 유저가 주문 목록을 확인할 수 있다. Entity 관계 설정 Entity는 기본적으로 User와 Item 이 있다. 근데 유저 A가 사과를 주문할수도 있고 유저 B가 사과를 주문할수도 있다. 반대로 유저 A가 사과, 바나나, 포도도 구매할 수 있다. 그래서 유저와 아이템은 N:M 의 다대다 관계가 생성된다. 하지만 테이블 설계를 User 와 Item으로만 설정한다면 주문 목록에 대한 속성값 추가가 어렵게된다. 그래서 주문 테이블을 추가하기로했다. 하지만 여전히 주문과 ..

기존의 CRUD 과정이 계속해서 반복되기에 전체 과정을 블로그로 남긴다. 기본 환경 - Kotlin (Java 11) - Spring Boot 2.7.16 - Gradle-Groovy Spring Initializer를 사용하여 생성했다. Dependency는 최소화하기위해 3개만 추가했다. - Spring Web - Spring Data JPA - H2 Database 이렇게 프로젝트를 생성했고 build.gradle 파일은 다음과 같다. import org.jetbrains.kotlin.gradle.tasks.KotlinCompile plugins { id 'org.springframework.boot' version '2.7.16' id 'io.spring.dependency-management' ..

1. 설득의 무기 의사결정을 내릴때 상세한 원인을 파악하기보단 특정한 행동(트리거)이 더 중요하게 작용한다. (왜냐하면을 붙이면 어떤사유던간에 양보를 해줌, 물건이 비싸면 품질에 상관없이 좋다고 생각해 구입) -> 의사결정의 효율성 문제. (선택의 가성비가 좋음) 쉬운 판단(지름길) -> 적은 고민(누르면 작동), 가성비 결과 -> 그러나 본질은 파악못함(오판할 확률 높아짐) 어려움 판단 -> 깊은 고민(의지와 능력이 있을때), 타당한 결과 -> 그러나 많은 에너지를 소모(시간이 부족) 상대가 쉬운 판단을 한다는것을 알게되면 누군가는 그것을 이용한다. (일부러 가격을 높혀서 판매해 좋은 상품인것처럼 속임) 상대가 쉬운 판단을 한다는것을 알면 주짓수처럼 상대의 선택을 이용할 수 있다. 그니까 조심해라. (..

1. Dockerfile 생성 도커 파일을 만들기 위해 환경설정 파일 구성. 'Dockerfile' 이라는 이름으로 만든다. 아래는 예시 # 베이스 이미지 java 17 FROM openjdk:17-jdk-alpine # 작업 디렉토리 생성 RUN mkdir -p /home/minecraft WORKDIR /home/minecraft COPY . . # EXPOSE 25565 EXPOSE 25565 # 페이버 서버 실행 CMD java -jar ./paper-1.19.4-538.jar 해당 파일을 프로젝트에 같이 넣어준다. 2. 도커 이미지 빌드 이제 터미널을 켜고 해당 dockerfile을 이미지 형태로 만들기 위해 빌드! $ docker build --tag shininghyunho/project:1..