MSA가 등장하기 전에는 모놀리식이라는 구조라고 할 것도 없이 모놀리식 구조로 개발해왔다고 한다.
단, 프로젝트의 규모가 커짐에 따라 하나의 어플리케이션을 도메인 성격에 따라 여러 개의 작은 서비스로 나누어 개별적으로 관리하는 MSA구조가 등장하게 되었다.
Hexagonal 구조 vsLayered 구조
모놀리식이건 MSA건 각 서비스가 가져야할 구조는 어떤 것들이 있을까?
먼저 모놀리식 아키텍처가 개발의 기본이었던 것과 마찬가지로 Layered구조(오른쪽)이 가장 기본적인 형태의 구조였다. Layered 구조는 데이터베이스를 중심으로 중심으로 설계했다. HTTP요청(User)를 DB에 저장하는 방법에 대해 고민하였고, 이를 가장 명료하게 구현하는 방식은 MVC패턴이 대표적인 디자인 패턴이 아닐까 싶다.
그러나 MSA가 등장한 이유와 같이, 요즘의 복잡해진 어플리케이션들은 비즈니스 로직이 수시로 변경되기도 하고 추가적인 종속성이 끊임없이 발생한다. 이러한 과정에서 Layered 구조는 종속성 혼란을 겪기도 한다.
이에 대한 대비책은 Hexagonal 구조를 채택하는 것이다. Hexagonal 구조는 비즈니스 로직을 중심으로 외부와 내부를 격리한다. 즉, 내부에 비즈니스 로직을 수행하는 계층을 두고 Port를 통해 외부와 통신하며 동작한다.
결과적으로 Hexagonal 구조를 사용하면 쉽게 수정할 수 있고, 경계를 명확하게 구분지어 격리된다.
[이 부분은 도메인 주도 설계인 DDD의 내용과도 밀접한 관계를 가지고 있으므로, 다음 편에서 조금 더 설명한다.]
MSA구조를 선택하면서 중요시해야 할 점들은?
모든 구조는 시스템 성능을 위해 존재한다. 그리고 시스템 성능을 평가하는 지표는 Thoughput과 Latency로 설명할 수 있다.
Thoughput : 처리량을 측정한다. 단위 시간당 얼마나 많은 작업을 처리할 수 있는지를 나타낸다.
Latency : 지연시간을 의미한다. 특정 작업을 완료하기 위해 걸리는 시간을 나타낸다.
MSA에서는 각 서비스 별로 관리하기 때문에 확장이 쉽다. 따라서 Thoughput관점에서는 장점을 가진다고 할 수 있다.
반면, Latency관점에서는 서비스 간 통신, DB 액세스 같은 외부 통신에서 기존의 모놀리식 구조에 비해 약점을 가지고 있다.
그러므로 아키텍처 설계 과정에서 MSA를 선택하는 것이 무한정 좋은 것은 아니며, Thoughput과 Latency를 최적화하는 지점을 찾는 것이 중요하다.
@Controller 계층은 MVC패턴에서 클라이언트의 요청에 대응해 결과를 뷰에 전달하여, 웹 페이지를 생성한다.
@Slf4j와 log를 통해 로거 인스턴스를 생성한다.
return "home"은 home.html 페이지를 반환함을 의미한다.
@Controller
@Slf4j
public class HomeController {
@RequestMapping("/")
public String home() {
log.info("home controller");
return "home";
}
}
회원 컨트롤러 개발
@Controller
@RequiredArgsConstructor
public class MemberController {
private final MemberService memberService;
/members/new로 들어오는 HTTP의 GET과 POST 메서드를 처리한다.
GET메서드가 들어올 때,
createForm은 모델 파라미터를 통해 뷰에 데이터를 전달하고 회원가입 폼을 생성하는 메서드다.
모델 파라미터에는 "memberForm"이라는 이름의 빈 멤버 폼 객체가 뷰로 전달된다.
뷰는 회원가입 폼 화면을 반환한다.
POST메서드가 들어오면,
@Valid를 통해 생성된 멤버 폼 객체의 유효성을 검증하고 BindingResult를 통해 결과를 확인한다.
만약 결과가 에러를 가지고 있다면, members/createMemberForm 뷰로 이동한다.
성공한다면, 홈 페이지로 redirect한다.
@GetMapping(value = "/members/new")
public String createForm(Model model) {
model.addAttribute("memberForm", new MemberForm());
return "members/createMemberForm";
}
@PostMapping(value = "/members/new")
public String create(@Valid MemberForm form, BindingResult result) {
if (result.hasErrors()) {
return "members/createMemberForm";
}
members로 GET메서드가 들어오면,
멤버 리포지토리에서 findAll로 찾아온 값을 반환하는 멤버서비스의 findMembers메서드로 members라는 List를 생성한다.
모델 파라미터에 "members"라는 이름의 members값을 뷰로 전달한다.
@GetMapping(value = "/members")
public String list(Model model) {
List<Member> members = memberService.findMembers();
model.addAttribute("members", members);
return "members/memberList";
}
주소 객체를 만드는데 form의 정보들을 변수로 불러와 생성한다.
새로운 멤버 정보를 빈 객체를 생성한 뒤, 폼에서 입력받은 이름 값과 생성된 주소값을 설정한다.
생성된 멤버 값은 멤버 서비스 계층에서 만든 회원가입 join 메서드를 활용해 멤버 서비스에 보내 DB에 반영시킨다.
화면은 redirect:/를 통해 홈화면으로 돌아간다.
Address address = new Address(form.getCity(), form.getStreet(),
form.getZipcode());
Member member = new Member();
member.setName(form.getName());
member.setAddress(address);
memberService.join(member);
return "redirect:/";
}
@Repository
@RequiredArgsConstructor
public class OrderRepository {
private final EntityManager em;
public void save(Order order) {
em.persist(order);
}
public Order findOne(Long id) {
return em.find(Order.class, id);
}
주문 서비스 개발
@Service계층, 읽기 전용, 생성자 주입을 통해 틀을 갖춘다.
주문 서비스는 회원, 주문, 상품 리포지토리를 모두 주입받는다.
@Service
@Transactional(readOnly = true)
@RequiredArgsConstructor
public class OrderService {
private final MemberRepository memberRepository;
private final OrderRepository orderRepository;
private final ItemRepository itemRepository;
주문 서비스는 주문과 주문상품 엔터티에서 생성한 비즈니스 로직을 통해 기능 위임한다.
=> 도메인 모델 패턴을 통해 비즈니스 로직을 구현하는 메서드를 엔터티에서 사용하고 있기 때문에, 서비스 계층은 구현이 아닌 로직을 호출하고 트랜잭션을 관리하여, DB에 반영하는 역할을 수행한다.
=> 이후, 도메인 주도 설계 DDD에 대해 공부할 것.
회원id, 상품id, 수량을 변수로 받아 id값을 통해 리포지토리에서 반환했던 엔터티 값을 조회한다.
빈 배송정보 객체 생성한 뒤, 받아온 회원 엔터티의 주소 정보를 배송정보의 주소정보로 설정한다.
도메인에서 생성한 비즈니스 로직인 주문상품과 주문을 생성한다.
리포지토리에 구현된 주문 정보를 저장하고 id값을 반환한다.
//주문
@Transactional
public Long order(Long memberId, Long itemId, int count) {
//엔티티 조회
Member member = memberRepository.findOne(memberId);
Item item = itemRepository.findOne(itemId);
//배송정보 생성
Delivery delivery = new Delivery();
delivery.setAddress(member.getAddress());
//주문상품 생성
OrderItem orderItem = OrderItem.createOrderItem(item, item.getPrice(), count);
//주문 생성
Order order = Order.createOrder(member, delivery, orderItem);
//주문 저장
orderRepository.save(order);
return order.getId();
}
추상클래스는 직접 객체 생성이 불가능하다. 상속을 통해 확장하고 자식(하위)클래스에서 구현된다.
상품 클래스가 가진 속성은 아래와 같다.
상품 id (PK)
이름
가격
재고수량
카테고리 목록
@Inheritance와 @DiscriminatorColumn은 상속 관계 매핑에서 단일 테이블 전략에 사용된다.
@Inheritance은 아래와 같이 전략 타입을 설정한다.
InheritanceType.SINGLE_TABLE: 단일 테이블 전략
InheritanceType.JOINED: 조인 전략
InheritanceType.TABLE_PER_CLASS: 구현 클래스마다 테이블 생성 전략
@DiscriminatorColumn을 dtype으로 명명해 하위 클래스의 값을 구분하여 다형성을 구현한다.
하위 클래스는 @DiscriminatorValue에 "값"을 지정해 단일 테이블 내에서 구분될 수 있다.
@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "dtype")
@Getter @Setter
public abstract class Item {
@Id @GeneratedValue(strategy = GenerationType.IDENTITY)
@Column(name = "item_id")
private Long id;
private String name;
private int price;
private int stockQuantity;
상품 엔티티는 stockQuantity라는 정수 값을 갖는다.재고 수량은 주문에 따라 변화하는 값이며, 0이하로 내려갈 수 없는 성격을 가지고 있다.따라서, 추가적인 비즈니스 로직이 필요하고 예외 처리를 위한 로직도 작성해야 한다.
public void addStock(int quantity) {
this.stockQuantity += quantity;
}
public void removeStock(int quantity) {
int restStock = this.stockQuantity - quantity;
if (restStock < 0) {
throw new NotEnoughStockException("need more stock");
}
this.stockQuantity = restStock;
}
}
add와 remove를 통해 증감을 계산하고, if문의 restStock이 0보다 작은 경우 예외처리를 수행한다.
package jpabook.jpashop.exception;
public class NotEnoughStockException extends RuntimeException {
public NotEnoughStockException() {
super();
}
public NotEnoughStockException(String message) {
super(message);
}
public NotEnoughStockException(String message, Throwable cause) {
super(message, cause);
}
public NotEnoughStockException(Throwable cause) {
super(cause);
}
protected NotEnoughStockException(String message, Throwable cause, boolean enableSuppression, boolean writableStackTrace) {
super(message, cause, enableSuppression, writableStackTrace);
}
}
비체크 예외인 RuntimeException을 상속 받아 생성자를 두고 다양한 예외에 대응한다.자바에서는 체크 예외와 비체크 예외를 통해 예외 처리를 한다. 이후 예외 처리에 대해 공부할 것.
상품 리포지토리 개발
@Repository
@RequiredArgsConstructor
public class ItemRepository {
private final EntityManager em;
public void save(Item item) {
if (item.getId() == null) {
em.persist(item);
} else {
em.merge(item);
}
}
public Item findOne(Long id) {
return em.find(Item.class, id);
}
public List<Item> findAll() {
return em.createQuery("select i from Item i",Item.class).getResultList();
}
@PersistenceContext에서 엔티티 매니저를 주입해 도메인에서 만들어 둔 엔티티를 관리한다.
save(), findOne(), findAll(), findByName() 메서드를 통해 본격적으로 기능을 구현한다.
@Repository
public class MemberRepository {
@PersistenceContext
private EntityManager em;
1. save(Member member) 메서드:
save를 통해 전달 받은 Member 객체를 persist메서드를 사용하여 영속성 컨텍스트에 저장한다.
이후 서비스 계층에서 트랜잭션이 커밋되면, DB에 반영된다.
2. findOne(Long id) 메서드:
Member의 주어진 id를 찾는 메서드이다.
1차적으로 영속성 컨텍스트내의 캐시에서 조회를 한 후, 없다면 JPA가 직접 데이터베이스에 select구문을 만들어 조회한다. 이는 id가 식별자이기 때문에 가능한 것이다.
em.find(클래스, 기본키)
3. findAll() 메서드:
DB에 저장된 모든 회원을 List로 반환한다.
select m from Member m을 통해 모든 회원을 조회하는 쿼리 구문을 생성한다.
select 쿼리가 실행된 후 getResultList를 통해 리스트로 받아온다.
4. findByName(String name) 메서드:
매개변수인 이름값으로 조회하는 방법
이름에 들어갈 내용은 동적인 데이터이기 때문에 setParameter 매개변수 바인딩을 사용해 안정적으로 제공한다.
예를 들면,
select m from Member m where m.name = 'John' 이 쿼리에서는 .setParameter("name", John)이 된다.
public void save(Member member) {
em.persist(member);
}
public Member findOne(Long id) {
return em.find(Member.class, id);
}
public List<Member> findAll() {
return em.createQuery("select m from Member m", Member.class)
.getResultList();
}
public List<Member> findByName(String name) {
return em.createQuery("select m from Member m where m.name = :name", Member.class)
.setParameter("name", name)
.getResultList();
}
}
회원 서비스 개발
@Service 서비스 계층임을 나타내며, readOnly = true를 통해 읽기 전용으로 사용된다.
즉, 데이터의 수정은 일어나지 않음을 의미한다.
@RequiredArgsConstructor를 통해 생성자를 자동으로 생성하여, ItemRepository를 주입받는다.
(final 또는 @NonNull로 표시된 필드를 사용하여, 생성자를 만든다.)
생성자 주입을 하는 이유:
리포지토리에서 구현된 회원 정보를 외부에서 받아와 사용하기 때문에 유연성과 재사용성의 장점을 가진다.
리포지토리의 회원 정보를 수정하더라도 서비스의 내용은 수정하지 않아도 된다.
@Service
@Transactional(readOnly = true)
@RequiredArgsConstructor
public class MemberService {
private final MemberRepository memberRepository;
메서드에서 id를 반환하는 이유:
새로운 회원정보가 데이터베이스에 저장되고 회원id가 반환되어야 클라이언트가 이 정보를 활용할 수 있다.
로그인, 회원 정보 수정 등에 활용된다.
//회원가입
@Transactional
public Long join(Member member) {
validateDuplicateMember(member);
memberRepository.save(member);
return member.getId();
}
private void validateDuplicateMember(Member member) {
List<Member> findMembers = memberRepository.findByName(member.getName());
if (!findMembers.isEmpty()) {
throw new IllegalStateException("이미 존재하는 회원입니다.");
}
}
회원조회는 사용하지 않고 회원가입에만 Transactional이 사용된 이유:
Transactional을 사용하는 이유는 트랜잭션을 통해 리포지토리에서 구현한 정보를 DB에 반영하기 위함이다.
즉, 가입에는 새로운 회원 정보를 DB에 저장해야 하지만 회원 조회에서는 새로운 값을 넣는 것이 아닌 get을 통한 호출만 다루고 있기 때문에 Transactional이 필요하지 않다.
// 전체 회원 조회
public List<Member> findMembers() {
return memberRepository.findAll();
}
public Member findOne(Long memberId) {
return memberRepository.findOne(memberId);
}
}
