[keyword] 5장 - 소프트웨어에서 표현되는 모델

[JasonYoo1995]

주제

'5장 - 소프트웨어에서 표현되는 모델'을 읽고 내용을 요약하거나,
중요✨ 하다고 생각하는 키워드 및 관련 설명을 코멘트로 달아주세요

연관 챕터

24

[wooyounggggg]

p.84

어떤 객체가 연속성(continuity)과 식별성(identity, 각종 상태를 바탕으로 추적되거나 서로 다 른 구현에 걸쳐 존재하는 것)을 지닌 것을 의미하는가? 아니면 다른 뭔가의 상태를 기술하는 속 성에 불과한가? 이것은 ENTITY와 VALUE OBJECT를 구분하는 가장 기본적인 방법이다.

Entity와 VO의 의미 및 차이

p.85

이를테면, 일대다(one-to-many) 연관관계는 인스턴스 변수에 들어 있는 컬렉션으로 구현할 수 도 있다. 하지만 설계도 반드시 그렇게 되는 것은 아니다. 어쩌면 컬렉션이 없을 수도 있고, 접근자 메서드(accessor method)에서 데이터베이스를 조회해서 적절한 레코드를 찾은 다음 해당 레코드를 토대로 객체를 인스턴스화할 수도 있다. 이러한 설계는 모두 동일한 모델을 반영할 것이다.

동일한 모델에 대해 구현이 여러가지로 나타날 수 있음.

p.86

도메인을 더욱 깊이 있게 이해하다 보면 굉장히 자주 “한정적인(qualified)” 관계에 이른다.

도메인에 대한 이해가 깊어짐으로써, 한정적인 관계를 발견하고 설계를 단순화 할 수 있다. 역으로, 처음(도메인에 대한 이해가 있기 전)부터 단순하고 완벽한 설계를 하는 것이란 불가능하다.

p.87

물론 당면한 문제에 필요한 것이 아니거나 중요한 의미를 담고 있는 모델 객체가 아니라면 궁극적인 단순화는 연관관계를 완전히 제거하는 것이다.

왜지?

p.108

또한 SERVICE의 매개변수와 결과는 도메인 객체여야 한다.

이 사례에서 이야기하는 도메인 객체의 범위를 모르겠음. Command나 Result같은 클래스도 포함하나? case study를 해보면 좋을 것 같네요.

p.111

구성 단위가 세밀한 객체는 도메인에서 지식이 새어 나오게 해서 도메인 객체의 행위를 조정하는 응용 계층으로 흘러가게 할 수 있다.

구성 단위가 세밀한 것과, 도메인 지식이 응용 서비스로 흘러가는 것이 어떤 연관 관계가 있을까? 어떤 얘기를 하는지 모르겠음

[leejaeseung]

연관관계를 최대한 제거하는 방향을 책에서 얘기하는데, 다양한 시스템을 연동하는 플랫폼 시스템에서 연관관계의 중요성이 돋보이는 듯 합니다.

A 서비스의 특정 필드들로 데이터를 가공하는 플랫폼이 있다고 한다면 단순하게 플랫폼에서 A 서비스의 필드를 컬럼으로 가지고 있을 수 있겠죠. 하지만 이는 A 서비스와 강한 결합을 갖게 되고, 서비스가 추가될 때마다 새로운 컬럼이 생겨나게 됩니다. 플랫폼 입장에선 A 서비스에 대한 정보가 중요한 의미를 담고 있지 않은데 불필요한 연관관계를 맺은 것이죠.

최근에 이런 시스템을 설계하고 있는데 여러 서비스와의 연동성을 고려해서 다른 서비스와의 연관관계를 그저 JSON 형태로 저장하려 합니다. 특정 서비스와 연관관계를 맺지 않고 서비스 측에서 자신의 연동 정보를 주면(JSON 을 어떻게 해석할지?) 그에 맞는 작업을 하는 형태가 될 것 같네요. 비즈니스 로직은 계속 추가되고 예측 불가능하므로 연관관계를 최소한으로(혹은 아예 없게) 가져간다면 서비스들을 더 유연하게 만들 수 있을 것 같습니다.

[leejaeseung]

p.121

객체 패러다임이 지배적인 이유

• 많은 사람에게 널리 알려져있어 패러다임을 학습하는 노력이 많이 들지 않는다. 결국 패러다임을 잘 이해해야 좋은 설계가 나오기 때문.
• 꼭 객체지향을 사용해야 하는 것은 아니다. 다만 객체지향이 가장 효율적인 방법일 뿐이다.

새로운 패러다임을 채택하는 프로젝트에서는 해당 기술에 전문성이 있거나 선택된 패러다임에 효과적인 모델을 만들어내는 숙련된 개발자들을 찾기가 불가능할지도 모른다.(p.121)

새로운 패러다임을 적용하는 건 개발자로써 상당히 흥미로운 일이겠지만 많은 걸 고려할 필요가 있겠죠. 얼핏 들은 얘기론 타 팀에서 scala 로 개발된 프로젝트를 java, kotlin 으로 바꾼다는 소문을 들었는데 널리 통용되지 않는 패러다임의 단점의 예시인 것 같습니다.