반응형
아주 바보같은 생각이었다. 회원이 바버샵과 연관이 있다고 회원을 나눈다니.
이번 프로젝트 설계의 가장 근간은 회원은 절대 지킨다였다. 그런데, 회원이 바버샵과 연관이 있다고 회원 도메인에 바버샵 도메인을 침투시킨다? 무슨 이런 바보같은...
회원과 바버샵이 연관되어 있으면, 회원이 바버샵에 의존하는게 아니라 바버샵이 회원에 의존하는게 맞다. 이런 기본 원칙을 까먹고 멍청하게 프로젝트를 진행하고 있었다....
이전에 생각했던 바버와 바버샵 클래스를 코드로 표현하면 아래와 같다.
class Barber {
...
private final BarberShop workPlace;
...
}
//////////////////////////////
class BarberShop {
...
private final Barber chief;
...
}
실로 어이없는 일이 아닐 수 없다. 아니 왜 바버랑 바버샵의 연관관계를 회원 도메인을 찢어가면서, 억지로 회원에 주입시켜가면서 진행하려 했을까.
회원과 바버샵의 연관을 만들고 싶었으면 아래 코드처럼 작성했어야 했다.
class Member {
기존의 Member 코드 유지
}
//////////////////////////////
class BarberShop {
...
private final Member chief;
private List<Member> workers;
...
}
BarberShop에서 Member를 바라봐야지 Member에서 BarberShop을 바라봐서는 안된다. 근무자들을 일급 컬렉션으로 다루면 좀 더 깔끔하지 않을까 싶다.
class BarberShop {
...
private final Workers workers;
...
}
이런 형태로 도메인을 다뤄야지 바보같은 생각 때문에 되지 않는 추상화를 엄청 오래 붙잡고 있었다... 코드를 롤백하고 다시 진행해보자.
반응형
'Programming > Study' 카테고리의 다른 글
중간 테이블은 어느 도메인에 위치시켜야할까? (1) | 2024.03.26 |
---|---|
바버 - 바버샵 최종장 : 중간 테이블... 써야겠지? (0) | 2024.03.03 |
구체 클래스 vs 추상 클래스 vs 인터페이스 - 고객 / 바버 추상화하기 (0) | 2024.02.27 |
일대다 단방향 연관관계를 피하고 싶어서 (0) | 2024.02.21 |
DB Entity -> Domain Entity로의 전환은 어느 계층에서 담당하는 것이 옳을까 (2) | 2024.02.14 |
댓글