안녕하세요, 우빈님! 정말 좋은 강의를 제공해주셔서 감사합니다. 제가 고민하던 주제에 관해 다뤄주셔서 정말 흥미를 가지고 강의를 들을 수 있었습니다☺강의를 다 들은 시점에 개발 공부를 시작한 이래로 늘 가지고 있던 오랜 궁금한 점이 있어서 이렇게 질문을 남기게 되었습니다! 조금 장문이 될 수도 있을 거 같네요🥲스프링을 사용해서 개발하게 되면 제일 처음 배우는 구조가 Controller -> Service -> Repository 이런 구조인데요, 보통 비즈니스 로직은 Service 에 작성된다고 배웠습니다. Service 레이어에서 모든 게 처리되고 비즈니스 로직이 도메인 쪽에 위치하지 못 하게 되는 것 같습니다. 애초에 도메인이라는 개념 자체가 없고 바로 JPA 엔티티를 만들고 @Service 어노테이션이 붙은 클래스에서 모든 걸 다 처리하는 거 같아요. 제가 국비 교육에서 배운 팀 프로젝트나 3개월 간 짧게 경험해 본 실무에서도 다 이렇게 코드를 짰던 거 같습니다. 공부하다보니 이런 걸 트랜잭션 스크립트 라고 하는 거 같더라구요.그런데 아무리 생각해도 이런 방식은 객체지향적이지 않다는 생각을 지울 수가 없었습니다. 제가 객체지향의 사실과 오해, 오브젝트 등에서 읽은 객체의 역할, 책임, 협력 이런 것들을 적용해보지 못 하는 것 같아서 객체지향적으로 코드를 짜는 것은 어떤 것일까 하는 갈망이 늘 있었습니다. 이런 갈망이 있어서 이번 강의를 더 간절히 기다렸던 거 같아요😀이번 강의는 스프링이나 데이터베이스를 전혀 사용하지 않고 순수 자바로만 객체지향에 대해서 설명을 해주셨는데요, 만약 스프링과 데이터베이스 기술(JPA) 등을 사용한다고 할 때는 어떻게 처리하시는 지 궁금합니다.이와 관련해서 제가 공부한 건 JPA 엔티티와 별개로 도메인 역할을 하는 클래스를 만들고 해당 클래스에서 비즈니스 로직을 처리하게 하고 도메인 객체를 JPA 엔티티로 변환해서 데이터베이스에 저장하는 방식이었습니다. (도메인 객체와 영속성 객체를 분리한 것이라고 할 수 있을 거 같습니다.) 이렇게 하면 도메인 객체 안에 있는 비즈니스 로직을 단위 테스트 하기도 쉽고(도메인 객체는 순수 자바(코틀린) 코드로만 돼 있으니까요!) 데이터베이스 중심적이지 않고 도메인 중심적으로 생각을 할 수 있는 것 같다는 인상을 받았습니다.다만 이렇게 할 때는 어떤 개념을 통해 도메인을 추출해야할 지, 그리고 책임을 어떤 도메인에 넣어야 할 지 고민할 게 많더라구요. 근데 약간 소설의 등장인물을 설정하는 거 같아서 재미는 있었습니다 ㅎㅎ 이렇게 접근을 하니 @Service 어노테이션이 붙은 클래스는 단순히 객체들이 모여서 서로 협력할 수 있게 해주는 광장(?) 이라고 해야될까요, 중개해주는 역할만 하게 되는 것 같다는 생각을 해보기도 했습니다.이러다 보니 DDD 에 대해서도 많이 관심을 갖게 됐습니다. 도메인 위주로 설계 하고 도메인에게 적절한 역할을 할당하는 방식인 거 같아서요. 그리고 아키텍처에도 많이 관심이 생기더라구요. 단순히 Controller -> Service -> Repositoy 구조의 레이어드 아키텍처에선 처음 언급한 문제를 해결하는게 쉽지 않아 보였거든요. 주절주절 질문이 길었는데 요약을 해보자면 다음과 같습니다. 스프링, JPA 같은 기술과 접목했을 때 이번 강의에서 배운 추상, 객체지향적 개발 방식을 어떻게 적용할 수 있을까요?이후로 공부할 만한 주제로 DDD, 아키텍처 등이 적절할까요? 비전공으로 혼자서 백엔드 개발자 취업 준비 중이라 질문할 곳이 마땅치 않아 여기에 이렇게 남기는 점 미리 양해를 구합니다😭

안녕하세요! 강의 너무 잘 듣고 있습니다!개발을 진행하면서 항상 네이밍 관련된 부분이 정말 어려운거 같네요ㅜㅜ추상화 레벨 파트를 수강하다가 궁금한 점이 있어서 질문드립니다! 같은 boolean형을 반환하는 메서드인데 doesUserWinTheGame()처럼 doesXxx()와, isAllCellIsOpened()처럼 isXxx() 두 가지 형태를 사용하셨는데, 주로 어떤 상황에서 does를 사용하시고, is를 사용하시는지 궁금해서 질문드립니다!