- 대부분의 개발자가 새로운 시스템을 설계하라는 요청을 받으면,
즉시 데이터베이스 스키마를 그리기 시작하고, 그 다음에 객체 모델을 생각한다.
여기서부터 모든 것이 잘못되기 시작한다...
•
이에 매우 공감한다. 그 이유는 대학교 졸업 작품을 이런식으로 설계해봤기 때문에 얼마나 비효율적이고 수정이 많이 발생하는지 느꼈기 때문이다.
•
물론 아닌 경우도 있지만 대부분 객체를 만들고 저장에 대한 요구사항은 행동에 맞춰서 정의하는 편이 더 나았다.
•
이 책에서는 아래 4가지의 핵심 설계 패턴을 소개한다.
1. 저장소 패턴은 영속적인 저장소에 대한 추상화를 한다.
2. 서비스 계층 패턴은 유스케이스의 시작과 끝을 명확하게 정의하기 위한 패턴이다.
3. 작업 단위 패턴은 원자적 연산을 제공한다.
4. 애그리게이트 패턴은 데이터 정합성을 강화하기 위한 패턴이다.
Markdown
복사
값 객체와 엔티티
•
값 객체는 값들이 실제로 어떤 역할을 하는지에 대해서 실세계에서 갖는 직관과 부합한다.
•
예를 들어서 10 파운드를 말할 때 10 파운드라는 값(가치)가 중요하지 어떤 지폐인지는 중요하지 않다.
•
파이썬에서는 아래와 같이 표현할 수 있다.
@dataclass(fronzen=True)
class Money:
currency: str
value: str
class Money(NamedTuple):
currency: str
value: int
Java
복사
•
그와 반대로, 오래동안 정체성이 존재하는 도메인 객체를 설명할 때는 엔티티라는 용어를 사용한다.
•
사람인 경우에는 자신의 이름이나 결혼 상태를 바꿀 수 있으며 심지어는 성별도 바꿀 수 있다. 하지만 이러한 변경에도 불구하고 모두 같은 사람으로 계속 인식 할 수 있다.
•
사람은 이름과 다르게 영속적인 정체성이 있다. 따라서 엔티티에는 정체성 동등성이라는 특징이 있다. 이는 엔티티의 값을 바꾸더라도, 바뀐 엔티티는 이전과 같은 엔티티로 인식된다는 것이다.
class Batch:
...
def __eq__(self, other):
if not isinstance(other, Batch):
return False
return other.reference == self.reference
def __hash__(self):
return hash(self.reference)
Java
복사
•
값 객체의 경우에는, 모든 값 속성을 사용하여 해시를 정의하고 객체를 반드시 불변 객체로 만들어야 한다.
•
데이터 클래스에 대해서 @frozen=True를 지정하면 공짜로 이런 동작을 얻을 수 있다.
•
오랫동안 유지되는 정체성이 존재하는 도메인 객체를 설명할 때 사용한다.
◦
이름을 Name이라는 클래스로 정의한다면 이름이 다른 Name객체는 서로 같지 않다. 하지만 Name객체를 갖는 사람(Person) 클래스는 영속적인 정체성(persistent identity)을 갖고 있다.
◦
따라서 값 객체와 달리 엔티티에는 정체성 동등성(identity equality)이 있다.
•
엔티티의 경우, 가장 단순한 선택은 해시를 None으로 지정하는 것이다. 이 객체에 대해서 해시를 계산할 수 없고 따라서 그에 따라서 집합 등에서 사용할 수 없다는 것이다.
•
특정한 이유로 엔티티를 집합(SET)에 넣거나 딕셔너리(DICT)의 키로 사용해야 한다면 시간과 무관하게 엔티티의 정체성을 식별해주는 속성을 사용하여 해시를 정의해야 한다. 그리고 어떻게 든 이 정체성을 식별해주는 속성을 읽기 전용으로 만들어야 한다.
도메인 모델링
도메인 모델링
•
도메인 모델링은 여러분의 코드에서 비즈니스와 가장 가까운 부분이다. 변화가 생길 가능성이 가장 높은 부분이고, 비즈니스에서 가장 큰 가치를 제공하는 부분이다. 도메인 모델링을 이해하고 변경하기 쉽게 만들어보자.
엔티티와 값 객체 구분
•
값 객체는 그 내부의 속성들에 의해서 정의된다. 불변 타입을 사용해서 값 객체를 구현하는 것이 가장 좋다. 반대로 엔티티에는 시간에 따라서 변하는 속성이 포함될 수 있고, 이런 속성은 바뀌더라도 여전히 똑같은 엔티티로 남는다. 어떤 요소가 엔티티를 유일하게 식별하는지 정의하는 것이 중요하다.
모든 것을 객체로 만들 필요가 없다
•
파이썬은 다중 패러다임 언어이다. 따라서 여러분의 코드에서 동사에 해당하는 부분을 표현하려면 함수를 사용하는 것이 좋다.
•
이는 자바를 하다가 파이썬으로 변경하였을 떄 가장 헷갈리는 것중에 하나이다.
•
모든 FooManager(관리 객체), BarBuilder(빌더 객체), BazFactory(펙토리 객체) 대신에 함수를 사용하는 것이 가독성이 좋고, 표현력이 더 좋다.
가장 좋은 설계 원칙을 적용할 때다
•
SOLID 원칙이나 has-a와 is-a의 관계 상속 보다는 합성을 사용하라와 같은 좋은 설계법을 살펴보고 이를 사용하는 것이 좋다.
책을 읽으면서 들은 질문들을 정리할 예정에 있습니다
1.
책에서 말하는 엔티티와 흔히 아는 엔티티 개념의 차이
a.
엔티티 : 데이터 베이스 테이블을 매핑하는 클래스
b.
책에서의 엔티티 : 객체 그 자체인 것 같은 느낌
2.
52pg에 나오는 정체성 동등성
데이터 클래스의 엔티티의 값을 바꿔도 바뀐 엔티티는 같은 엔티티로 인식되기에 정체성 측면에서 동등하다..!
위 의미를 어떻게 해석해야할까
일단 필자는 파이썬의 객체 메모리 측면에서 이해를 했다.
파이썬의 객체는 생성되면, 그 객체가 기록될 주소가 배정되는데, 그러한 주소가 동일하다면, 엔티티는 동일하다. 라고 인식되는 것이 아닐까
그렇기 때문에 위에서 hash를 통해 그 참조 주소를 알아내려 한 것이 아닐까