키친포스의 요구 사항과 용어 사전, 모델링을 기반으로 메뉴 CONTEXT를 리팩터링한다.
메뉴 CONTEXT의 도메인 계층만 먼저 구현한다.
menus 패키지 밑에 tobe.domain 패키지를 만들고 거기서부터 구현을 시작한다.
용어 사전과 모델링이 부자연스럽거나 불완전하거나 잘못된 경우 지속적으로 수정한다.
새로운 모델에 맞게끔 클래스, 메서드, 모듈의 이름을 다시 지으면서 코드를 리팩터링한다.
REPOSITORY 구현 시 자신에게 익숙하고 편한 것을 선택하여 진행한다.

• https://stackoverflow.com/questions/978061/http-get-with-request-body
• https://developer.twitter.com/en/docs/twitter-api/v1/accounts-and-users/follow-search-get-users/api-reference/get-users-lookup

You are strongly encouraged to use a POST for larger request

코틀린 + 스프링: 박재성

매장 식사 주문 CONTEXT의 도메인 계층만 먼저 구현한다.
eatinorders 패키지 밑에 tobe.domain 패키지를 만들고 거기서부터 구현을 시작한다.

최범균; JpaRepository 를 상속하지 않는 이유

순수 Repository 인터페이스는 domain 패키지에,
이를 실제로 구현해서 DB 인프라 닿는 JpaRepository 는 infra 패키지로 분리해서
application 에 있는 Service 가 domain 의 Repository 에만 의존하도록 하고, JpaRepository 를 직접 의존하는 일이 없도록 하자.

• next-step#34
• next-step#44
• next-step#47
• next-step#59

http://aeternum.egloos.com/1160846

CONTEXT 간의 연동을 구현한 다른 프로젝트 참고

• domain 패키지의 OrderProduct
• domain 패키지의 OrderProductMapper 인터페이스

package orders.domain

import commons.model.OrderSheet;

import java.util.List;

public interface OrderProductMapper {
    List<OrderProduct> mapFrom(List<OrderSheet.OrderSheetItem> orderSheetItems);
}

• 이것을 구현하는 integrate(= infra) 패키지의 RemoteOrderCatalogsService

package orders.integrate;

import java.util.List;
import java.util.stream.Collectors;

import lombok.AllArgsConstructor;
import commons.model.OrderSheet;
import orders.domain.entity.OrderProduct;
import orders.domain.entity.OrderProductItem;
import orders.domain.entity.OrderProductMapper;
import orders.integrate.catalogs.Product;
import orders.integrate.catalogs.ProductRepository;

@AllArgsConstructor
public class RemoteOrderCatalogsService implements OrderProductMapper {
    private ProductRepository productRepository;

    @Override
    public List<OrderProduct> mapFrom(List<OrderSheet.OrderSheetItem> orderSheetItems) {
        return orderSheetItems.stream().map(orderSheetItem -> {
            // 생략
        }).collect(Collectors.toList());
    }

    private Product getProductFor(OrderSheet.OrderSheetItem item) {
        return productRepository.getProduct(item.getProductId());
    }
}

Object vs Datastructure

DDD 철학으로 개발된 프레임워크는 Spring Data JDBC 입니다. JPA와 같은 ORM 프레임워크가 DDD 철학으로부터 비롯된 것인지는 다시 살펴 봐야 될 것 같아요! 준석님이 말씀하셨던 것처럼 JPA의 엔티티는 기술의 구현체로 봐야 하고, DDD의 엔티티는 기술적 관심사와 분리하여 봐주시면 좋을 듯 합니다. 그렇기 때문에 원론적으로 구현하시는 분은 도메인 모델에 JPA 애너테이션 사용도 기술의 침범이라고 봅니다. 저는 이 부분에 대해 트레이드오프라고 생각하고 분리하는 것보다 함께 사용할 때 편리한 점이 더 많았다고 설명하였습니다. 결과적으로 DDD의 엔티티에 해당하지만 기술적으로 값 객체처럼 구현할 수도 있고, 값 객체지만 JPA의 엔티티로도 구현할 수 있습니다. 아래의 글도 참고하세요!

https://stackoverflow.com/questions/57148900/jpa-entity-responsibility-in-domain-driven-design

키친포스의 요구 사항과 용어 사전, 모델링을 기반으로 상품 CONTEXT를 리팩터링한다.
상품 CONTEXT의 도메인 계층만 먼저 구현한다.
products 패키지 밑에 tobe.domain 패키지를 만들고 거기서부터 구현을 시작한다.
용어 사전과 모델링이 부자연스럽거나 불완전하거나 잘못된 경우 지속적으로 수정한다.
새로운 모델에 맞게끔 클래스, 메서드, 모듈의 이름을 다시 지으면서 코드를 리팩터링한다.

domain 을 리팩토링할 때, 클래스명이 같아서 객체 생성이 제대로 되지 않는 문제 어떻게 해결해야하는지 조언 부탁드립니다!
가령 domain.Product 와 tobe.domain.Product 의 클래스명이 같다고,
JPA 가 엔티티 객체를 생성하지 못하고 서버가 터져서요.

마찬가지로 리팩토링된 domain 에 맞추어,
tobe.domain.ProductService 를 새로 만들었을 때,
기존의 domain.ProductService 와 클래스명이 같아서,
빈 팩토리가 의존성 주입을 제대로 하지 않는 문제는 어떻게 해결해야하는지 질문드립니다.

지금은 무식하게 클래스명 앞에 Tobe 라고 접두어를 붙였습니다.

우아한 객체지향 2단계 예제

여기에 나온 것을 바탕으로 DomainService 를 구현해보자.

Event Sourcing

이벤트를 날려서 서비스 간에 의존성을 없애버릴 수가 있다.