WebMaster

새로운 할인 정책을 확장해보자. 시나리오 악덕 기획자: 서비스 오픈 직전에 할인 정책을 지금처럼 고정 금액 할인이 아니라 좀 더 합리적인 주문 금액당 할인하는 정률% 할인으로 변경하고 싶어요. 예를 들어서 기존 정책은 VIP가 10000원을 주문하든 20000원을 주문하든 항상 1000원을 할인했는데, 이번에 새로 나온 정책은 10%로 지정해두면 고객이 10000원 주문 시 1000원을 할인해주고, 20000원 주문 시에 2000원을 할인해주는 거예요! 순진 개발자: 제가 처음부터 고정 금액 할인은 아니라고 했잖아요. 악덕 기획자: 애자일 소프트웨어 개발 선언 몰라요? “계획을 따르기보다 변화에 대응하기를” 순진 개발자: … (하지만 난 유연한 설계가 가능하도록 객체지향 설계 원칙을 준수했지 후후) 참고..

주문과 할인 정책 회원은 상품을 주문할 수 있다. 회원 등급에 따라 할인 정책을 적용할 수 있다. 할인 정책은 모든 VIP는 1000원을 할인해주는 고정 금액 할인을 적용해달라. (나중에 변경될 수 있다.) 할인 정책은 변경 가능성이 높다. 회사의 기본 할인 정책을 아직 정하지 못했고, 오픈 직전까지 고민을 미루고 싶다. 최악의 경우 할인을 적용하지 않을 수 도 있다. (미확정) 주문 도메인 협력, 역할, 책임 주문 생성: 클라이언트는 주문 서비스에 주문 생성을 요청한다. 회원 조회: 할인을 위해서는 회원 등급이 필요하다. 그래서 주문 서비스는 회원 저장소에서 회원을 조회한다. 할인 적용: 주문 서비스는 회원 등급에 따른 할인 여부를 할인 정책에 위임한다. 주문 결과 반환: 주문 서비스는 할인 결과를 포..

회원 도메인 요구사항 회원을 가입하고 조회할 수 있다. 회원은 일반과 VIP 두 가지 등급이 있다. 회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다. (미확정) 회원 도메인 협력 관계 회원 클래스 다이어그램 회원 객체 다이어그램 회원 도메인 개발 Grade.class Member.class public class Member { private Long id; private String name; private Grade grade; public Member(Long id, String name, Grade grade) { this.id = id; this.name = name; this.grade = grade; } public Long getId() { return id; }..

회원 회원을 가입하고 조회할 수 있다. 회원은 일반과 VIP 두 가지 등급이 있다. 회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다. (미확정) 주문과 할인 정책 회원은 상품을 주문할 수 있다. 회원 등급에 따라 할인 정책을 적용할 수 있다. 할인 정책은 모든 VIP는 1000원을 할인해주는 고정 금액 할인을 적용해달라. (나중에 변경될 수 있다.) 할인 정책은 변경 가능성이 높다. 회사의 기본 할인 정책을 아직 정하지 못했고, 오픈 직전까지 고민을 미루고 싶다. 최악의 경우 할인을 적용하지 않을 수 도 있다. (미확정) 요구사항을 보면 회원 데이터, 할인 정책 같은 부분은 지금 결정하기 어려운 부분이다. 그렇다고 이런 정책이 결정될 때까지 개발을 무기한 기다릴 수 도 없다. ..

사전 준비 Java 11 설치 IDE: IntelliJ 또는 Eclipse 설치 https://start.spring.io/

스프링은 다음 기술로 다형성 + OCP, DIP를 가능하게 지원 DI(Dependency Injection): 의존관계, 의존성 주입 DI 컨테이너 제공 클라이언트 코드의 변경 없이 기능 확장 쉽게 부품을 교체하듯이 개발 정리 모든 설계에 역할과 구현을 분리하자. 자동차, 공연의 예를 떠올려보자. 애플리케이션 설계도 공연을 설계하듯이 배역만 만들어두고, 배우는 언제든지 유연하게 변경할 수 있도록 만드는 것이 좋은 객체 지향 설계다. 이상적으로는 모든 설계에 인터페이스를 부여하자 실무 고민 하지만 인터페이스를 도입하면 추상화라는 비용이 발생한다. 기능을 확장할 가능성이 없다면, 구체 클래스를 직접 사용하고, 향후 꼭 필요할 때 리팩토링해서 인터페이스를 도입하는 것도 방법이다

SRP: 단일 책임 원칙(single responsibility principle) OCP: 개방-폐쇄 원칙 (Open/closed principle) LSP: 리스코프 치환 원칙 (Liskov substitution principle) ISP: 인터페이스 분리 원칙 (Interface segregation principle) DIP: 의존관계 역전 원칙 (Dependency inversion principle) SRP: 단일 책임 원칙 한 클래스는 하나의 책임만 가져야 한다. 하나의 책임이라는 것은 모호하다. 클 수 있고, 작을 수 있다. 문맥과 상황에 따라 다르다. 중요한 기준은 변경이다. 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것 예) UI 변경, 객체의 생성과 사용을 분리 ..

다형성 자동차가 변경된다고 운전자에게 영향을 줄까? 주지 않는다 자동차 역할에만 운전자가 의존하기 있기 때문에 자동차가 변경되어도 상관없는 것이다. 로미오, 줄리엣 역할을 주연은 변경이 가능해야 된다 로미오, 줄리엣이라는 역할을 누가 할지는 중요하지 않다(클라이언트 대상이 누구이든지 상관없이 동일하게 동작해야 한다) 역할과 구현을 분리 역할과 구현으로 구분하면 세상이 단순해지고, 유연 해지며 변경도 편리해진다. 장점 클라이언트는 대상의 역할(인터페이스)만 알면 된다. 클라이언트는 구현 대상의 내부 구조를 몰라도 된다. 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다. 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다 자바 언어 자바 언어의 다형성을 활용 역할 = 인터페이스 구..

스프링 프레임워크 핵심 기술: 스프링 DI 컨테이너, AOP, 이벤트, 기타 웹 기술: 스프링 MVC, 스프링 WebFlux 데이터 접근 기술: 트랜잭션, JDBC, ORM 지원, XML 지원 기술 통합: 캐시, 이메일, 원격 접근, 스케줄링 테스트: 스프링 기반 테스트 지원 언어: 코틀린, 그루비 최근에는 스프링 부트를 통해서 스프링 프레임워크의 기술들을 편리하게 사용 스프링 부트 스프링을 편리하게 사용할 수 있도록 지원, 최근에는 기본으로 사용 단독으로 실행할 수 있는 스프링 애플리케이션을 쉽게 생성 Tomcat 같은 웹 서버를 내장해서 별도의 웹 서버를 설치하지 않아도 됨 손쉬운 빌드 구성을 위한 starter 종속성 제공 스프링과 3rd parth(외부) 라이브러리 자동 구성 메트릭, 상태 확인,..

dockerfile dockerfile 생성 kafkaConsumerConfig 수정 docker build docker push docker run docker run -d --network ecommerce-network \ --name catalog-service \ -e "spring.cloud.config.uri=[config 서버]" \ -e "spring.rabbitmq.host=[rabbitMQ 서버]" \ -e "eureka.client.serviceUrl.defaultZone=[유레카 서버]" \ -e "logging.file=[로그파일 등록]" \ widn45/[이미지 파일]:[tag]