Layered Architecture

테스트하기 어려운 부분 분리,

테스트 하고자 하는 영역에 집중,

명시적이고 이해할 수 있는 형태의 문서 작성 가능

여러 가지 모듈이 합쳐진 결과를 우리는 예상 할 수 있는가?

이를 위한 통.합.테.스.트

통합 테스트

🔸 여러 모듈이 협력하는 기능을 통합적으로 검증하는 테스트

🔸 일반적으로 작은 범위의 단위 테스트만으로는 기능 전체의 신뢰성을 보장할 수 없다.

🔸 풍부한 단위 테스트 & 큰 기능 단위를 검증하는 통합 테스트

Library vs. Framework

내 코드가 주체가 되어서 필요한 기능은 외부에서 끌어다 옴 vs. 이미 갖춰진 동작 환경에서 내 코드가 수동적으로 역할을 하게 됨

Spring

🔸 Ioc (Inversion of Control)

객체의 생명주기를 주관해서. 필요한 객체가 있을때 필요한 객체를 제3자가 만들어서 주입해줌

🔸 DI (Dependency Injection)

생성자를 주입해서 사용함. 어디서 온 것인지는 알 수 없음(주는 것만 사용)

🔸 AOP (Aspect Oriented Programming)

비즈니스 흐름과 관계없는 부분을 하나로 모아서 다른 모듈로 분리해서 사용(스프링에서는 프록시 사용해서 구현 함)

ORM (Object-Relational Mapping)

객체지향에 대한 개념과 관계형 DB 간의 패러다임이 달라서 DB에 넣기에 어려움

🔸 객체 지향 패러다임과 관계형 DB 패러다임의 불일치

🔸 이전에는 개발자가 객체의 데이터를 한땀한땀 매피하여 DB에 저장 및 조회(CRUD)

🔸 ORM 을 사용함으로써 개발자는 단순 작업을 줄이고, 비즈니스 로직에 집중할 수 있다.

JPA. (Java Persistence API)

🔸 Java 진영의 ORM 기술 표준

🔸인터페이스이고, 여러 구현체가 있지만 보통 Hibernate를 많이 사용한다.

🔸 반복적인 CRUD SQL 을 생성 및 실행해주고, 여러 부가 기능들을 제공한다.

🔸 편리하지만 쿼리를 직접 작성하지 않기 때문에, 어떤 식으로 쿼리가 만들어지고 실행되는지 명확하게 이해하고 있어야 한다.

🔸 Spring 진영에서는 JPA를 한번 더 추상화한 Spring Data JPA 제공

🔸 QueryDSL 과 조합하여 많이 사용한다. (타입체크, 동적쿼리에 대한 장점. 실무에서는 필수로 사용하지만 강의의 범위를 넘어섬)

🔸@Entity 테이블 과 객체를 매핑, @Id , @Column Entity 정의

🔸@ManyToOne 두 객체간의 연관관계, @OneToMany, @OneToOne, @ManyToMany(일대다 - 다대일 관계로 풀어서 사용)

엔티티 설계

Order 와 Product 는 다대다 관계로서. 주문 입장에서 여러 음료수, 음료수 입장에서 여러 주문들이 된다.

다대다 관계는. 일대다, 다대일 관계로 풀어서 접근할 것

Order — OrderProduct — Product

요구사항

🔸 키오스크 주문을 위한 상품 후보 리스트 조회하기

🔸 상품의 판매 상태 : 판매중, 판매보류, 판매중지

→ 판매중, 판매보류인 상태의 상품을 화면에 보여준다

🔸 id, 상품 번호, 상품 타입, 판매 상태, 상품 이름, 가격

Persistence Layer

🔸 Data Access 의 역할(여기에 집중한 레이어)

🔸 비즈니스 가공 로직이 포함되어서는 안 된다. Data에 대한 CRUD에만 집중한 레이어

Business Layer

🔸 비즈니스 로직을 구현하는 역할

🔸 Persistence Layer 와의 상호작용(Data를 읽고 쓰는 행위) 을 통해 비즈니스 로직을 전개시킨다.

🔸 트랜잭션을 보장해야 한다.(로직을 전개하다 문제가 생기면 롤백해야 하기에, 롤백에 대한 트랜잭션을 보장해 줘야 한다). 작업 단위에 대한 원자성