할인 조건의 구현에 대해

qwerty143님 안녕하세요. 강의가 도움이 되신다니 다행이네요. 🙂 좋은 질문 남겨주셔서 감사합니다. Screening의 isSequece 메서드와 SequenceCondition의 isSatisfiedBy 메서드는 책임의 관점에서 의미가 다릅니다. Screening의 isSequence 메서드는 회차가 동일한지를 판단합니다. Screening의 입장에서 isSequence 메서드는 할인 여부와는 상관이 없습니다. SequenceCondition의 isSatisfiedBy 메서드는 할인을 적용할 수 있는지 여부를 판단합니다. 회차가 동일할 경우 할인을 제공하기 때문에 Screening의 isSequnce 메서드를 재사용하고 있을 뿐입니다. 이런 의미적인 차이는 회차를 이용한 할인 여부 로직을 수정할 때 좀 더 명확해 지는데요만약 특정한 요일의 특정 회차에만 할인을 적용해야 한다면 다음과 같이 SequenceCondition의 isSatisfiedBy 메서드를 수정하게 될것입니다.아래 코드를 Screening에 구현하게 되면 Screening의 응집도가 낮아지게 됩니다.public class SequenceCondition implements DiscountCondition { private int sequence; private DayOfWeek dayOfWeek; @Override public boolean isSatisfiedBy(Screening screening) { return screening.isSequence(sequence) && screening.getStartTime().getDayOfWeek().equals(dayOfWeek); } } screening.getStartTime().getDayOfWeek(dayOfWeek)처럼 객체의 내부 속성을 연쇄적으로 가져오면 디미터 법칙(Law of Demeter)을 위반하기 때문에 객체의 인터페이스가 너무 복잡해지지 않는다면 screening.isScreenedOnDayOfWeek(dayOfWeek)과 같이 수정하는 것이 더 좋은 방법이기는 합니다. 답변이 되었는지 모르겠네요. 🙂

generic 패키지 money 클래스 관련 질문

황설탕님 안녕하세요.좋은 질문해 주셔서 감사합니다.말씀하신 것처럼 강의 내용을 확실하게 이해하는 가장 좋은 방법은 실제로 코드를 작성하는데 적용해 보는 것 같아요. :)Money 클래스가 있는 generic 패키지는 보통 어떤 특성을 가지는 클래스들을 모아놓는지 궁금합니다.개인적으로 특정한 도메인이나 애플리케이션에 종속되지 않고 여러 애플리케이션에서 재사용할 수 있는 클래스들을 모아 놓습니다.Money 클래스는 금액이 필요한 어떤 애플리케이션에서도 재사용가능하기 때문에 generic 패키지에 위치시켰습니다. Money 클래스와 같은 역할을 하는 객체들 또한 행동을 정의한 후 객체를 선택하라의 원칙에 의해 행동을 정의 한 후 필드를 결정하는 것인지 궁금합니다.Money와 같은 유형의 객체는 일반적으로 클래스의 코드를 리팩터링하는 과정에서 함께 사용되는 필드들과 관련된 로직을 명시적인 개념으로 묶기 위해 사용됩니다.따라서 행동을 정의한 후 객체를 선택하는 방식과는 조금 다른 관점에서 설계가 진행됩니다.필드가 아니라 로직을 담는 클래스를 추가한다는 점에서 행동에 집중한다는 점은 동일하지만 협력을 설계하는 과정에서 행동을 먼저 결정하고 객체를 나중에 결정한다기 보자는 이미 구현된 로직을 옮겨 담을 객체를 추가한다는 개념으로 접근하는게 일반적입니다. Money 같은 성격의 클래스는 어떤 서비스를 설계하기 전 전 미리 작성한 후 서비스 설계를 해야하나요?2번 질문에서 답변드린 것처럼 일반적으로 기존 코드를 리팩터링하는 과정에서 Money와 같은 유형의 객체가 추가됩니다.물론 Money처럼 여러 도메인에 걸쳐 사용될 수 있는 클래스라면 이미 구현되어 있는 클래스를 재사용하기도 하겠지만 도메인에 특화된 객체나 존재하지 않는 경우에는 구현을 하면서 식별되는 것이 일반적입니다. Money 는 새 불변 객체를 만들어 리턴해주는 방식으로 사용하던데 Screening 등의 클래스에서는 불변 객체를 사용하지 않는 이유가 있는지, 있다면 특정 클래스를 불변 객체로 설계하는 기준이 있는지 궁급합니다.Money는 값 객체(Value Object)에 속하고 Screening은 참조 객체(Reference Object)에 속합니다.값 객체는 참조 객체의 속성을 표현하기 위해 사용되며 불변으로 만드는 것이 일반적입니다.값 객체와 참조 객체의 개념과 용도에 대해서는 제 블로그에 있는 시리즈 글을 참고하시면 쉽게 이해하실 수 있으실 거에요. :)https://eternity-object.tistory.com/2답변이 되었는지 모르겠네요. 🙂 감사합니다.

DiscountCondition을 DiscountPolicy 뒤에 숨겨야 하는 이유

ttt123님 안녕하세요.좋은 질문 남겨 주셔서 감사합니다.현재 코드 구조를 그려보면 아래 그림처럼 Movie는 추상클래스인 DiscountPolicy에만 의존하고 있습니다.(사진) DiscountPolicy의 서브클래스들과 DiscountCondition은 추상클래스인 DiscountPolicy 내부에 숨겨져 있기때문에 Movie의 입장에서는 접근할 수가 없습니다.다시 말해서 Movie의 입장에서는 DiscountPolicy 추상클래스만 보이고 다른 클래스들은 보이지 않는 것이죠.이 개념은 캡슐화(Encapsulation)로 연결되며 Discountpolicy 추상클래스만 변경하지 않는다면 Movie는 영향을 받지 않게 됩니다.결과적으로 DiscountPolicy 클래스를 기준으로 구조를 변경하더라도 Movie에는 영향을 미치지 않는 것이죠.(사진) 만약 Movie가 DiscountPolicy와 DiscountCondition 모두에 의존한다면 변경에 의해 더 자주 영향을 받게 되었을 것입니다.변경의 영향을 최소화하기 위해 DiscountCondition을 DiscountPolicy 뒤로 숨겼다고 생각하시면 될것 같아요. 6-3. 결합도와 6-4. 캡슐화를 보시면 더 깊이 있게 이해하실 수 있으실거에요. 🙂 보시고 궁금한 점 있으면 또 질문 남겨 주세요!

영화 예매 도메인 코드 작성

안녕하세요.정확하게 질문하신 어떤 부분이라는게 무엇을 의미하시는지 알 수 없어 일단 제가 생각하는 답을 드리도록 할게요.혹시 질문하신 의도와 거리가 있다면 추가적으로 질문을 남겨 주시면 감사하겠습니다. 🙂 기능을 구현하는 순서는 크게 두 가지로 구분할 수 있습니다.Outside-In : 프리젠테이션 레이어부터 도메인 로직을 향해 코드를 완성해가는 방법Inside-Out: 도메인 로직을 완성한 후 그 위에 서비스 레이어나 프리젠테이션 레이어를 얹는 방법 사람에 따라 선호하는 방법은 다를 수 있지만 제 개인적으로는 강의에서 보여드린 것처럼 Inside-Out 방식을 선호합니다.하지만 프로젝트를 할 때는 Inside-Out 방식을 무조건 고수하기 보다는 상황에 적절한 방식을 선택하게 됩니다.도메인 로직을 먼저 구현하지만 상황에 따라 유연하게 작업 순서를 조정한다고 생각하시면 될것 같아요. 🙂감사합니다.

안녕하세요. 기존의 추상화된 역할에 대해서 새로운 협력자가 필요하게 되는 경우는 어떻게 설계해야할까요??

윤철님 안녕하세요.좋은 질문 남겨주셔서 감사합니다. 🙂추상화의 역할은 '현재 알고 있는' 변경을 캡슐화해서 코드 수정으로 인해 받을 수 있는 영향을 최소화하는 것입니다.여기에서 '현재 알고 있는' 변경이라는 점이 중요한데 어떤 부분이 변경될지 모르는 상황에서 예상에 기반해서 설계할 경우 불필요한 추상화를 도입하게 되고 결과적으로 코드를 수정하게 되기 때문입니다.현재 알고 있는 변경은 Screening의 데이터에 따라 할인 여부가 달라진다는 사실이기 때문에 Screening에 의존하고 있지만 그 시점에 어떤 데이터가 필요할지 알지 못하기 때문에, 그리고 Screening이 아닌 다른 요소들에 기반해서 할인 여부를 판단하도록 요구사항이 변경될지 알지 못하기 때문에 현재와 같은 클래스 구조를 유지했다고 생각하시면 될 것 같아요.실제로 Screening 이외의 데이터를 필요로하지 않는다면 현재 코드는 그 사실을 명확하게 보여줍니다.실제로 코드가 변경되고 새로운 추상화가 필요하다면 그 사실을 코드에 반영하면 됩니다.말씀하신 경우에는 객체가 아닌 가격 계산에 필요한 항목들을 포함하는 새로운 객체를 추가해서 해결할 수 있을 것 같습니다.public class PriceFactors { private Screening screening; private Customer customer; public PriceFactors(Screening screening, Customer customer) { this.screening = screening; this.customer = customer; } public Money getFixedFee() { return screening.getFixedFee(); } public boolean isSequence(int sequence) { return screening.isSequence(sequence); } public LocalDate getBirthdate() { return customer.getBirthdate(); } }그리고 Movie, DiscountPolicy, DiscountCondition의 오퍼레이션이 PriceFactors를 전달받도록 수정합니다.public interface DiscountCondition { boolean isSatisfiedBy(PriceFactors factors); }이제 BirthdateCondition을 다음과 같이 구현할 수 있습니다.public interface BirthdateCondition implements DiscountCondition { @Override public boolean isSatisfiedBy(PriceFactors factors) { return factors.getBirthdate().equals(LocalDate.now()); } }새로운 요구사항으로 인해 많은 클래스를 수정해야 하기 때문에 변경 전의 코드는 Screening 이외의 다른 요소를 이용해서 할인 여부 확인에 대해서는 취약한 설계라고 할 수 있습니다. 여기에서 긴장은 PriceFactors를 프로젝트 처음부터 추가할 수 없었느냐인데 새로운 할인 대상이 추가된다는 사실이 확정이 아닌 상태에서 기존 코드에 PriceFactors를 추가했다면 코드가 불필요하게 복잡해 보일것입니다. 다른 관점에서 Screening에 대해 모든 클래스가 의존하기 때문에 PriceFactors를 미리 추가하는 것이 도움이 된다고 생각할 수 있습니다. 이 경우 PriceFactors를 미리 추가하는 것이 더 합리적이라고 볼 수 있습니다.결국 PriceFactors와 같은 새로운 요소를 미리 도입할지 여부는 해당 변경에 대한 발생가능성과 발생했을 때 코드를 수정하기가 얼마나 어려운지에 따라 달라지게 됩니다.이제 PriceFactors를 이용해서 리팩터링했기 때문에 현재의 설계는 이런 유형의 변경을 안정적으로 추가할 수 있게 됐습니다. 하지만 현재 예상할 수 없는 새로운 유형이 요구사항이 추가된다면 리팩터링된 코드 역시 다시 수정될 수 밖에 없습니다.여기에서 눈여겨보실 부분은 Screening, Movie, DiscountPolicy, DiscountCondition의 역할과 협력 방식은 변경되지 않았다는 점입니다. 현재의 설계는 인터페이스는 변경되지만 객체의 역할과 책임 관점에서는 안정적이라고 할 수 있습니다.다음과 같이 정리할 수 있을것 같아요.예상하지 못했던 새로운 유형의 요구사항이 추가됐을 때 변경하지 않고 해당 요구사항을 수용할 수 없습니다. 현재의 요구사항에 적합한 추상화를 선택하세요.요구사항이 변경된다면 변경된 요구사항에 적합한 추상화를 이용해서 코드를 수정하세요. 하지만 예측에 기반해서 추상화를 도입하지 말고 실제로 변경이 일어날 때까지 기다렸다가 적합한 추상화를 도입하세요.요구사항이 너무 복잡해져서 현재의 추상화에 적합하지 않다면 전체적인 역할, 책임, 협력을 수정해야할 수도 있습니다. 현재의 추상화를 버리고 변경된 요구사항에 적합한 새로운 역할, 책임, 협력을 찾으세요.질문 중에 테스트가 매번 깨지는 상황이 발생할 수 있다고 하신 부분이 있는데 이건 아마도 테스트가 실패한다는 의미가 아니라 테스트 코드를 수정해야 하는 상황을 말씀하신 것 같아요. PriceFactors를 도입한 후에는 Customer와 Screening과 같은 요소에 기반해서 할인 정책이 변경되는 경우에는 테스트 코드를 수정할 필요가 없을 거에요. 하지만 기존에 알지 못했던 새로운 유형의 요구사항이 추가된다면 당연히 테스트 케이스는 수정될 수 밖에 없을 것입니다.정말로 코드 수정에 의해 테스트가 매번 수정된다면 3번과 같이 현재의 역할, 책임, 협력을 다시 고민해야 하는 좋은 기회로 삼을 수 있을것 같아요.요약하면 추상화와 캡슐화는 현재 알고 있는 변경을 드러낼 수 있는 것이면 됩니다. 미래의 요구사항은 알 수 없기 때문에 예상에 기반해서 불필요한 추상화를 미리 도입해서는 안됩니다. 대부분의 경우에 역할과 책임을 납득할만하게 할당하고 클래스와 메서드를 작게 유지한다면 생각보다 코드를 수정하기가 어렵지 않을거에요.답변이 되었는지 모르겠네요. 😄

도메인 추출 방법

JMJ님 안녕하세요. 좋은 질문 남겨 주셔서 감사합니다.애플리케이션 개발에 적합한 도메인 개념을 찾는 일은 저를 포함해서 모든 사람들이 어렵게 생각하는 작업이기 때문에 창피해 하실 일이 전혀 아닙니다.도메인 개념을 찾기 위한 다양한 패턴이나 카탈로그들이 제시되어 왔지만 모든 경우에 적용할 수 있는 최적화된 해법은 존재하지 않는 것으로 보입니다.애플리케이션마다 가정하고 있는 제약조건이 다르고 요구사항의 변화 양상이 다르기 때문에 어떤 도메인에 적합한 도메인 개념은 이것이다라고 말하기 어려운 것 같아요.다양한 자료를 보시고 많은 프로젝트 경험이 쌓일수록 조금 더 수월해지기는 하지만 아직도 여전히 어려운걸 보면 경험이 모든 것을 해결해 주지는 못하더라구요.제가 가장 쉽고 직관적이리고 생각하는 가이드는 다음과 같습니다.현재 시점에서 가장 단순하게 생각되는 개념들을 기반으로 우선 코드를 구현해봅니다.처음부터 모든 개념을 정확하게 추출하려고 하지말고 우선 생각나는 가장 간단한 개념들을 기반으로 코드를 작성하면서 고민했던 개념들이 현재 요구사항에 적합한지 최대한 빠르게 피드백을 받는 것이 좋습니다. 구현 시에 클래스가 응집도나 결합도 관점에서 너무 커지거나 복잡해진다면 새로운 개념을 추가한 후 일부 책임을 새로운 개념에 맡깁니다.이렇게 코드의 퀄리티를 높여야 하는 시점이 되면 도메인에 대해 좀 더 깊게 고민하게 되고 자연스럽게 새로운 도메인 개념이 도출되게 됩니다.요구사항이 변경되면 현재의 코드가 요구사항을 수용하기에 적합한지 판단하고 필요하면 새로운 도메인 개념을 기반으로 코드를 리팩터링합니다.요구사항이 변경되는 시점이야말로 새로운 도메인 개념을 추출할 수 있는 적절한 타이밍입니다. 지금까지 적합하지 않아 보이던 도메인 개념이 위치를 찾고, 적합해 보이던 도메인 개념이 여러 개의 더 작은 도메인 개념으로 나뉘기도 합니다. 리팩토링을 통해 새롭게 얻은 도메인 지식을 코드에 반영해야겠죠.도메인 개념이 고정된 것이 아니고 코드를 구현하거나 요구사항이 변경됨에 따라 지속적으로 변경된다는 사실을 의도적으로 인식하고 언제라고 리팩토링하신다면 적절한 시기에 적합한 도메인 개념들을 식별하실 수 있으실거에요.여기에 아래 인프런 AI가 제시하는 가이드가 나와있는 다양한 자료를 학습하시고 실제 프로젝트에서의 경험치를 쌓으신다면 좀 더 수월해지실 거라고 생각합니다. JMJ님뿐만 아니라 모든 분들이 어려워하시는 영역이고 한번에 적절한 도메인 개념들을 모두 식별하는 것은 어려운 작업이라서 지속적으로 리팩토링을 통해 적절한 도메인 개념을 식별한다는 마음으로 접근하시면 부담이 적어지실 거에요. 답변 중에 좀 더 세부적인 내용이 궁금하시면 질문해 주세요. 🙂 즐거운 주말 보내세요!

5-4- 예제. 애플리케이션 객체 추가하기 강의내용 관련 질문이 있습니다. (DAO)

모아무개님 안녕하세요.좋은 질문 주셔서 감사합니다. 🙂 정확하게는 인터페이스와 구현의 분리(separation of interface and implementation) 원칙에 해당되며 흔히 구현이 아닌 인터페이스에 대해 프로그램하라(program to an interface, not implementation)라는 가이드로 설명되고는 합니다. 예제에서 서비스가 DAO 구현 클래스가 아닌 인터페이스에 의존하는 이유는 불필요한 변경에 서비스 레이어가 영향을 받지 않게 만들고 싶기 때문입니다.구현 방식과 독립적으로 인터페이스(역할의 개념으로 생각하셔도 됩니다)와 오퍼레이션(책임의 개념으로 생각하셔도 됩니다)을 정의하고 클라이언트가 인터페이스에 의존하도록 만들면 https://www.inflearn.com/community/questions/1355997에서 설명한 것처럼 구현을 교체하거나 구현의 변경에 영향을 받지 않도록 좀 더 안정적인 코드 구조를 설계할 수 있게 됩니다. 질문 주신 내용은 결합도와 캡슐화와 연관이 깊은데요이 주제는 6-3. 결합도와 6-4. 캡슐화에서 자세히 다루고 있습니다. 답변이 되었는지 모르겠네요. 🙂

ReservationService 구현에서 SRP에 대해서 질문이 있습니다.

fzwoongbin닌 좋은 질문 주셔서 감사합니다. 🙂 1. reserveScreening과 SRP일반적으로 SRP라고 할 때는 주로 클래스를 대상으로 이야기하는 경우가 많지만 말씀하신 것처럼 메서드 역시 SRP의 대상이 될 수 있습니다.강의에서도 말씀드렸던 것처럼 사실 SRP는 응집도와 관련된 이야기입니다.하나의 변경 이유만 가지도록 클래스나 메서드를 구현한다면 응집도가 높아지기 때문에 결과적으로 SRP를 만족하게 됩니다.reserveScreening 메서드는 예약을 하기 위해 필요한 객체를 읽고, 도메인 로직에 요청을 위임하고, 수정된 결과를 저장하는 로직만 포함합니다.데이터를 읽거나 저장하고 상영이 예매되는 구체적인 로직은 별도의 객체들 안에 구현되어 있고 reserveScreening은 이들을 조합해서 상영을 예매하기 위한 전체 플로우를 완성시킵니다.HTTP 요청 파라미터가 변경되거나, 요청 데이터 검증 로직이 변경되거나, 반환값이 변경되거나, Screening과 Movie 사이의 협력이 변경되거나, SQL문이 변경될 경우에는 변경되지 않습니다.결과적으로 reserveScreening 메서드를 살펴보면 예약을 하기 위해 필요한 플로우가 변경될 때만 코드를 수정하게 됩니다.다른 기능은 다루지 않고 오직 예약을 위한 플로우만 담당하고 있습니다.따라서 reserveScreening은 응집도가 높다고 할 수 있으며 SRP를 만족한다고 할 수 있습니다. 2. Controller -> Repository 호출개인적으로 Service를 두는 쪽을 선호합니다.Controller에서 Repository를 직접 조회할 경우 비즈니스 로직이 Controller로 누수되는 경우도 많아지고 이후에 조회할 데이터가 늘경우 Controller가 불필요하게 복잡해지는 경향이 있게 됩니다.Service에 메서드를 두면 메서드 이름을 통해 조회하려는 의도를 전달할 수도 있구요.Controller는 프리젠테이션 로직만 담당하게 하고 데이터를 조회하고 변환하는 로직은 별도의 Service에 두는 것이 유지보수 측면에서 더 좋은 선택이라고 생각합니다. 3. 서비스 레이어의 역할앞에서 설명드린 것처럼 서비스 레이어는 플로우를 조율하는 역할을 담당합니다.플로우에서 실행되는 구체적인 로직은 Repository 구현체나 Screening과 같은 별도의 객체에서 수행되고 서비스 레이어는 이 객체들을 호출해서 전체적인 플로우를 완성합니다.간단히 말해서 서비스 레이어는 기술적인 요소와 도메인 객체 사이의 흐름(구체적인 구현이 아니라 호출만 합니다)을 조율하는데 필요한 책임을 담당합니다.비즈니스 관점에서 연산을 수행하는데 필요한 도메인 로직의 호출, 트랜잭션이 관리, 데이터베이스 조회/저장, 메시징을 통한 통지 등의 흐름 관리가 서비스 레이어의 주역할입니다. 답변이 되었는지 모르겠네요. 🙂

객체지향 설계 관련하여 궁금한것이 있습니다.

모아무개님 안녕하세요.좋은 질문 해주셔서 감사합니다. 강의의 앞부분에서는 도메인에 포함되는 개념과 관계를 코드로 옮기는 방법을 중심으로 객체지향 설계 방법을 설명하고 있습니다.이렇게 구현된 클래스들은 레이어 아키텍처에서 일반적으로 이야기하는 도메인 레이어에 위치하게 되며 자바에서는 패키지를 이용해서 레이어를 구분하게 됩니다.이 패키지의 이름은 말씀하신 것처럼 domain으로 짓는 것이 일반적입니다. 하지만 애플레케이션이 실제로 동작하기 위해서는 도메인 객체만으로는 충분하지 않습니다.도메인과 무관한 객체들도 필요한데 Spring을 사용하는 환경에서 이 객체들은 아래 인프런 AI 인턴이 설명하는 것처럼 repository, service, controller와 같은 이름이 붙은 패키지 아래 배치가 될것입니다.이 부분에 대해선 "5-4. 애플리케이션 객체 추가하기"에서 좀 더 자세히 설명하고 있습니다. 강의를 들으시는 분들 중에 JPA를 모르시는 분들도 계시기 때문에 강의에서는 JPA 대신 Spring의 JdbcClient를 기반으로 네이티브 쿼리를 사용하고, 퍼시스턴스 메커니즘을 담당하는 객체의 이름에 repository 대신 dao라는 이름을 붙이고 있지만 JPA를 사용하더라도 기본적인 구조는 동일하게 가져갈 수 있습니다.이론적인 부분에 대해서는 "5-4. 애플리케이션 객체 추가하기"를 참고해 주시고, 코드의 예는 "5-4-예제. 애플리케이션 객체 추가하기" 강좌를 참고해 주시면 감사하겠습니다. 보시고 궁금한 부분이 있으면 다시 문의해 주시면 답변 드리도록 하겠습니다.남은 강의도 재미있게 보시고 꼭 완강하시길 바랄게요. 🙂

2-4-예제, 절차에서 객체로 코드 오타 제보드립니다.

류재준님 안녕하세요. 🙂 제보해 주신 부분에 else 문이 들어가야 하지만 else문이 생략되고 if 문만 사용된 것을 확인했습니다.확인해보니 다행히 코드를 설명하는 동영상과 배포된 pdf에는 else 문이 정상적으로 사용되어 있어서 큰 이슈는 없지만 말씀해 주신 실습 동영상과 github에는 else문이 누락되어 있습니다.실행 결과에는 영향을 주지 않지만 표현력과 일관성 측면에서 오해를 불러일으킬 수 있어 github의 코드를수정했습니다.다만 동영상 자료는 세밀한 수정이 필요해서 일단 현재 상태를 유지하고 시간이 날 때 다시 업로드하도록 하겠습니다.강의 자세히 들어주시고 세세한 부분까지 확인해 주셔서 정말 감사합니다!