kth990303 commented 1 year ago

주제

4장 - 도메인의 격리을 읽고 내용을 요약하거나,
중요✨ 하다고 생각하는 키워드 및 관련 설명을 코멘트로 달아주세요

연관 챕터

19

kth990303 commented 1 year ago

한줄 요약: 비즈니스 로직과 UI 로직을 분리하고, 도메인은 본연의 책임에만 집중하게 하자

이번 챕터는 2부로 넘어온 만큼, 기획 쪽 얘기보다는 객체의 책임에 대한 얘기가 많이 나온 듯합니다.

키워드

도메인에 관련된 코드가 상당한 양의 도메인과 관련이 없는 다른 코드를 통해 널리 확산될 경우 도메인에 관련된 코드를 확인하고 추론하기가 굉장히 힘들어진다. UI를 표면적으로 변경하는 것이 실질적으로 업무 로직을 변경하는 것으로 이어질 수 있다. (p.71)

진리(이 책의 범위를 넘어서서 어디서든 지지받는 진리로서)는 바로 도메인과 UI를 분리해야 한다는 것이다. (p.79)

위 내용에서 말했듯이, UI 로직의 변경 요구사항으로 인해 UI 로직 뿐만 아니라 비즈니스 로직 코드를 수정해야 한다면 그 코드를 점검해볼 필요가 있다고 생각합니다. 웹 개발을 처음 했을 때 가장 먼저 받은 피드백과 내용이 같아서 그런지 기억에 강렬하게 남아있네요.

우리는 인간이고, 결국 생산 비용을 고려할 수밖에 없다고 생각하기 때문에 Smart UI보다는 객체지향 및 DDD에 대해 공부해보는 것 같아요. 만약 우리가 로봇이고 UI 로직 변경과 비즈니스 로직 변경을 거의 동시에, 별도의 에너지 낭비 없이 가능하다면 얘기가 달라지겠지만요 😅

분리의 주된 이점은 애플리케이션 계층이 단순해져서 애플리케이션 본연의 책임에만 집중하게 되는 것이며, 이로써 메시지를 "언제" 보내는지는 알아도 "어떻게" 보내는지는 알 필요가 없어진다. (p.75)

객체지향에서의 캡슐화에 대한 중요성을 언급하는 내용이라 생각합니다. "어떻게" 에 대해 다른 객체가 알고 있다는 것은 사실상 그 객체도 "어떻게"에 대한 로직에 관여하고 있다는 것이며, 의존성이 그만큼 강하다는 뜻이라 볼 수 있을 듯해요.

그리고 이러한 점은 테스트 코드를 작성함으로써 더 잘 지켜질 수 있다고 생각해요. 각 객체의 책임에 대해 테스트를 쉽게 할 수 있다면 그 객체에 대한 책임과 자율성이 올바르게 부여한 것이라 생각합니다 :)

아쉽게도 여러분의 우아한 도메인 모델은 그것을 더럽힐 수 있는, 다름아닌 인프라스트럭처나 사용자 인터페이스의 영향을 받는다. 여러분은 모델에 완전히 통합되지 않는 기타 도메인 구성 요소를 다뤄야 한다. 또한 같은 도메인에 대해 서로 다른 모델을 사용하는 다른 개발팀에 대처해야 할 것이다. 갖가지 이유로 여러분의 모델은 불분명해지고 모델의 효용성을 잃어버리게 될 수도 있다. 14장, "모델의 무결성 유지"에서는 이러한 주제를 다룰 것이며, BOUNDED CONTEXT와 ANTICOURRUPTION LAYER와 같은 패턴을 소개하겠다. 정말로 복잡한 도메인 모델은 그 자체로도 매우 다루기 어려워질 수 있다. (p.82)

사실상 우리가 끊임없이 설계와 아키텍처에 대해 공부하는 이유가 아닐까 싶습니다. 관심사 분리 및 모델 설계. 말이야 쉽지... 현실은 그렇지 않으니까요 😭

앞으로 열심히 달려봅시다~~~

wooyounggggg commented 1 year ago

p.71

도메인과 관련된 코드가 상당한 양의 도메인과 관련이 없는 다른 코드를 통해 널리 확산될 경우 도메인에 관련된 코드를 확인하고 추론하기가 굉장히 힘들어진다.

캡슐화를 통해 각 레이어를 격리하여 관심사를 분리하고, 로직의 누수를 예방해야 함

emiling commented 1 year ago

1부에서는 팀 내에서 DDD를 도입하기 위한 컨센서스를 맞추기 위한 태도나 사상과 관련되었다면 2부부터는 모델 주도 설계를 실제로 수행하기 위한 여러 원리와 요소, 개념들을 소개하려는 듯한 의도가 보였습니다.

왜 도메인을 격리해야할까? (p.69)

근본적인 질문인 "그렇다면 왜 도메인 격리를 해야해?" 에 대한 대답으로 아래와 같이 말합니다. (p.69)

도메인에서 발생하는 개별적 문제들을 시스템이라는 하나의 큰 덩어리 안에서 바라볼 수 있어야 함

이를 용이하게 하기 위해 도메인과 도메인과 관련이 적은 기능들로 부터 분리할 필요가 있음

이러한 격리를 위한 기법이 LAYERED ARCHITECTURE

요약하면 도메인과 도메인과 관련이 적은 기능으로 분리하여 전체 시스템 안에서 문제를 보기 편하게하려고 하고 이를 위한 전략 중 하나를 LAYERED ARCHITECTURE 라고 소개합니다.

LAYERED ARCHITECTURE

https://martinfowler.com/bliki/PresentationDomainDataLayering.html

복잡한 규모의 소프트웨어를 만들기 위해 관심사를 분리하여 격리된 상태에서 각 설계요소에 집중하여 응집도 있는 설계를 가능하게함
경험과 관계로 크게 네 가지 계층으로 나누어 다루고 있고 주의깊게 보고 싶은 점은 아래 두가지 계층입니다.
- 응용 계층 (Application Layer) : 업무 규칙이나 지식이 포함되지 않으며 오직 작업을 조정하고 아래에 위치한 계층에 포함된 도메인 객체의 협력자에게 작업을 위임한다.
- 도메인 계층 (Domain Layer) : 업무 개념이나 규칙, 업무 상황에 관한 정보 및 상태를 제어하고 사용하며 그와 같은 상태 저장과 관련된 기술적 세부사항은 인프라스트럭처에 위임한다.
- 📌 여러 프로젝트 코드들을 보다보면 (대부분) 도메인 계층에서 Java Persistence API 를 포함함 🤔 (링크)
결국 중요한 것은 MODEL-DRIVEN DESIGN 을 가능하게 하는 것은 결국 도메인 계층을 분리하는 데 있다.

계층간 관계 설정

응용 계층과 도메인 계층에 UI를 연결하는 패턴은 MODEL-VIEW-CONTROLLER(MVC)에서 유래한다

📌 Martin Fowler GUI Architectures: https://www.martinfowler.com/eaaDev/uiArchs.html

SERVICE의 범위와 인터페이스를 적절히 선정하고 설계한다면 호출하는 쪽은 SERVICE 인터페이스에서 캡슐화하는 정교한 행위를 바탕으로 느슨하게 결합할 수 있다.

이는 결국 객체지향에서 말하는 역할을 어떻게 정의하고 각각의 객체의 내부 구현을 캡슐화하여 어떻게 자율적인 객체로 만들 것인지에 대한 고민과 연결됨.

아키텍처 프레임워크

때때로 프레임워크는 여러 인프라스트럭처 요구사항을 통합하면서 일부 기술적인 문제가 침습적인 형태의 인프라스트럭처를 띄게 된다.

프레임워크의 목적은 도메인 모델을 표현하고 해당 도메인 모델을 이용하여 중요한 문제를 해결하는 구현을 만드는 데 있다.

일부 유용한 기능만 취사선택 하여 분별력 있게 사용하면 좋지만 때로는 도구에 아키텍처를 맞추는 경우도 생각보다 많죠 ㅎㅎ...

그래서 결론이...?

도메인을 분리하고 이를 위한 전략으로 LAYERED ARCHITECTURE를 고려해볼 수 있다.

JasonYoo1995 commented 1 year ago

emiling님께서 언급해주신

📌 여러 프로젝트 코드들을 보다보면 (대부분) 도메인 계층에서 Java Persistence API 를 포함함 🤔 (링크)

이 내용과 관련된 코드를 공유 드립니다

도메인 계층에서 Java Persistence API를 포함하지 않은 경우 : https://github.com/wikibook/clean-architecture
도메인 계층에서 Java Persistence API를 포함한 경우 : https://github.com/JasonYoo1995/spring-sample-project