헥사고날 아키텍처에서의 개발에 대한 생각

[Seongwon97]

업데이트 로직을 구현하다보니 우리가 올바르게 헥사거널을 사용하는 것인지에 대한 의문이 들었습니다.
저의 생각을 공유하고 다 같이 이야기를 나누어보면서 로직 작성의 틀을 잡는 것이 좋을 것 같아 Discussion을 남깁니다.
우선 이러한 생각이 든 이유는 아래와 같습니다.

1. Application는 과연 도메인이 맞는 것일까?

// JobInfo는 Application(지원서)객체의 상위 클래스
@Getter
@RequiredArgsConstructor
public abstract class JobInfo {

	protected final Long id;
	protected final String companyName;
	protected final String team;
	protected final String location;
	protected final String contact;
	protected final String position;
	protected final String specificPosition;
	protected final String jobDescription;
	protected final String workType;
	protected final EmploymentType employmentType;
	protected final String careerRequirement;
	protected final String requiredCapability;
	protected final String preferredQualification;
	protected final Processes processes;
	protected final String url;

	public List<Process> getProcesses() {
		return processes.getValues();
	}
}

현재 Application필드에는 모든 필드에 final이 붙어있습니다. 이러한 상태에서는 객체의 상태를 변경하는 업데이트 로직을 구현할 수가 없습니다.
현상태에서 유일하게 존재하는 방법은 아래의 두 가지 방법이 있다고 생각됩니다.

1. 객체에게 업데이트 요청을 하여 새로운 객체를 생성하여 반환한다
2. 객체를 거치지 않고 바로 요청 정보를 통해 application객체를 만들고 out-adapter에 해당 정보로 요청을 보낸다.

위의 두 가지 방법에 문제점을 각각 생각해보겠습니다.

첫번째 방법의 문제점

먼저 첫번째 방법은 객체지향적인 프로그래밍이 맞는지에 대한 의문이 듭니다. 조영호님의 객체지향의 사실과 오해을 읽어보면 객체의 행동의 결과로 객체는 자신의 상태를 변경하거나 다른 객체에게 메시지를 전달할 수 있다.라는 말을 합니다.
구현 방법의 새로운 객체를 반환한다는 것은 다른 객체에게 메시지를 전달할 수 있다에 해당할 것 같습니다. 하지만 해당 방법은 요청에 따른 응답 값을 가공해서 보내는 것이지 요청된 정보를 통해 자신을 복제하여 보내는 것이 맞는지는 모르겠습니다.
객체지향의 사실과 오해의 이상한 나라의 엘리스를 예로 들면 엘리스가 펜케이크를 먹었더니 엘리스의 키에 변동있는 것이 아니라 엘리스는 그대로 존재하고 엘리스의 분신이 생긴 느낌이 들었습니다.

두번째 방법의 문제점

두번째 방법은 Application을 객체가 아닌 DTO로 사용하는 방법이라는 생각이 들었습니다.
해당 방법의 문제점을 예시로 들면 업데이트 로직에 지원 공고를 통해 만든 지원서는 @@정보 수정이 안된다.라는 제약조건이 추가되었을때, 해당 로직은 도메인이 아닌 서비스 로직이 갖게 됩니다.
서비스가 1~2개의 로직을 가질 경우, 큰 문제가 발생하지 않겠지만 서비스의 제약조건이 많아질수록 서비스의 코드는 엄청나게 길어질 것입니다.
즉, 도메인이 가져야 할 제약조건들을 서비스로 넘기는 상황들이 발생하게 되며, 도메인을 DTO로만 사용하는 것이 아닌가 의심해볼 필요가 있다 생각합니다.

위의 내용들을 토대로 불변을 위해 application의 모든 필드에 final 키워드를 붙여야 하는지에 대해 생각해보면 좋을 것 같습니다.

2. Core와 Out-Adapter이 나눠갖는 책임의 경계

Core에서 어느정도로 로직을 처리하고 Out-Adapter에 어떤 처리까지 관리해줘야 할지에 대해 이야기를 나누어보면 좋을 것 같습니다.
해당 내용도 지원서 업데이트 로직을 만들면서 생각한 것인데요. 이해를 위해 코드로 한번 살펴보겠습니다.
먼저 현재 구현한 코드는 아래와 같습니다.
아래의 코드는 위의 1번 이야기의 2번 구현 방법을 통해 구현한 방법인데요! 해당 방법의 경우 변경할 Application객체를 만들어 넘겨주고 applicationPersistenceCommandPort에서는 Application객체를 전달받아 정보를 수정하게 됩니다.

@Service
@Transactional
@RequiredArgsConstructor
public class ApplicationCommandService implements ApplicationCommandPort {
	@Override
	public void updateSpecifically(Long userId, long applicationId, SpecificApplicationUpdateRequest request) {
		validateNotFound(userId, applicationId);

		applicationPersistenceCommandPort.update(request.toDomain(applicationId));
	}
}

@Component
@RequiredArgsConstructor
public class ApplicationPersistenceCommandAdapter implements ApplicationPersistenceCommandPort {
	...
	@Override
	public void update(Application application) {
		ApplicationJpaEntity applicationJpaEntity = applicationRepository.findById(application.getId())
			.orElseThrow();

		applicationJpaEntity.update(application);
		applicationProcessRepository.deleteByApplicationId(application.getId());
		List<Process> processes = application.getProcesses();
		saveApplicationProcesses(applicationJpaEntity, processes);
	}
}

ApplicationPersistenceCommandAdapter의 경우 3가지의 일을 하고 있습니다.

1. Application의 정보를 읽어와 수정한다. (Application테이블 접근 및 수정)
2. 기존의 관련된 지원 과정 데이터를 삭제한다. (ApplicationProcess테이블 접근 및 수정)
3. 새로운 지원 과정 데이터를 추가한다. (ApplicationProcess테이블 접근 및 수정)

저는 개인적으로 위의 3가지 일도 비즈니스 로직에 해당이 들기도 합니다.
로직을 최적화하면, 어떤 지원 과정이 변동이 없는 것인지, 어떤 지원과정이 새로 생긴 것인지, 어떤 지원 과정이 수정되고 삭제되었는지 등을 판단하고 적용해야할텐데 지금의 구조라면 해당 로직들은 모두 out-adapter에서 구현하게되어 복잡도가 높아집니다.

그래서 아래와 같이 core-domain단에서 로직을 처리하며 변경되고 삭제된 과정 등을 판단하고 그에 따라 out-adapter로 보내는 방법은 어떤가합니다.

사실 저도 해당 주제에 대해서는 "로직이 어디에 위치하는 것이 좋다!!"라는 생각은 없습니다. 위의 예시로 언급한 로직의 최적화의 경우, 결국 데이터베이스의 쿼리를 최적화하는 것이기에 해당 관심사를 core로 올리는 것이 과연 올바른 것일까..?하는 생각도 들기 때문입니다..

글이 길지만 다들 한번 읽고 해당 주제에 대해 이야기를 나눠보면 좋을 것 같습니다!!!