jpa를 쓰는 이유 중 하나가 객체지향적으로 개발을 하기 위함도 있는데
비즈니스로직이 쿼리에 녹아있다, 코드에 녹아있다 의 정확한 의미가 뭔지 좀 모르겠네
DB에서는 컬럼을 그대로 가져오기만 하고
= TRUE 라던가 EQUALS 라던가 이런 연산을 자바에서 처리하게 하고
update쿼리를 날리는게 아니라 엔티티를 수정해서 작업하는게
비즈니스 로직시 코드에 녹아있는건가
그리고 잘 묶으면 유지보수가 쉽다고 하는데
이때 묶는다는게 어떤걸 의미하는지??
MSA를 의미하는지 혹은 DDD 방식에서 애그리거트의 경계를 말하는지
기술적으로 JPA를 쓰는것과 별개로 명확히 하고 싶은 부분임
비즈니스로직이 쿼리에 녹아있다, 코드에 녹아있다 의 정확한 의미가 뭔지 좀 모르겠네
DB에서는 컬럼을 그대로 가져오기만 하고
= TRUE 라던가 EQUALS 라던가 이런 연산을 자바에서 처리하게 하고
update쿼리를 날리는게 아니라 엔티티를 수정해서 작업하는게
비즈니스 로직시 코드에 녹아있는건가
그리고 잘 묶으면 유지보수가 쉽다고 하는데
이때 묶는다는게 어떤걸 의미하는지??
MSA를 의미하는지 혹은 DDD 방식에서 애그리거트의 경계를 말하는지
기술적으로 JPA를 쓰는것과 별개로 명확히 하고 싶은 부분임
질문하는걸 보니 MSA니 DDD니 하는것보다 객체지향에 대한 공부가 더 필요할듯 싶은데 말 그대로 객체(엔티티)한테 일을 시킨다는거임
상품이라는 엔티티가 있고 이 엔티티는 재고와 판매 상태를 가진다 쳐보자. 재고가 0개가 되면 당연히 판매 상태도 품절로 바뀌어야 할거임. 쿼리 기반의 구조에서는, 이를 엔티티가 아닌 외부에서 setter, getter를 통해 재고를 확인하고 판매상태를 바꿔줄거임. 반면 객체지향을 잘 지킨 엔티티라면, 상품이라는 엔티티가 스스로 이것들을 챙김. 단순히 decreaseStock()이라는 인터페이스만 제공하고 이를 호출하면 내부적으로 알아서 상태를 관리하는 거지
쿼리 기반에선 이런 객체지향성을 지키기 힘들다보니(흔히 패러다임이 불일치한다고 말하지), JPA가 나오게 된거임. 그리고 니가 말한 데이터 중심이란 단어는 쿼리 기반과는 의미가 완전 다르다. 데이터 중심은 데이터의 관리, 흐름에 초점을 둔 아키텍처를 의미하는거고 현대의 대부분 아키텍처는 데이터 중심이라고 볼 수 있음
데이터랑 쿼리 중심은 개념이 다르구나 MSA랑 DDD는 객체중심 쿼리랑 별개의 질문이었음 이전에 JPA관련해서 그런 말도 봤어서
정확히는 MSA DDD를 물었다기보단 혹시 그것과 관련된거냐고 물은거
묶는다는건 내가 말한대로 '객체안에 로직을 얼마나 잘 쑤셔넣느냐'를 말함. 흔히 응집도라고 하지. DDD, MSA랑은 어느정도 관련이 있다고 볼순 있는데.. 다 응집도를 높이는 느낌이긴함
그럼 쿼리에 로직이 있는 예시라면 update stock set case when .... where product.id = ? 이런걸 얘기하나?
시바 이해 완전 잘 됐다 고맙다
그런 예가 있을수도 있고, JPA를 쓰더라도 '객체지향'이라는 개념을 잘몰라서 외부에서 setter, getter를 쓰면 이는 사실상 jap를 '더티체킹으로 자동으로 쿼리 날린다'정도로만 쓰는거겠지. 이 경우에도 객체지향을 잘지켰다기 보단 쿼리 위주로 나간다고 생각할수 있음
요는 관련된 주요 로직(흔히 도메인 로직이라고도 함)을 '엔티티'라는 하나의 단위에다가 다 때려박는거임. 이걸 지키지 못하면 주요 로직이 쿼리로 들어가거나, 위의 서비스, 컨트롤러 단 까지 새어나가는 거고.. 주요 로직임에도 여기저기 퍼져있으니까 유지 보수성이 떨어지는거임
잘 묶었다 = 공통적인 부분, 특징을 잘 캐치해서 추상화한다. 응집도는 높게 결합도는 낮게 모듈화를 잘 했다.. 이런 개념? 묻는거맞음?
잘 묶으면 붙이기도 쉽고 나누기도 쉬워서 유지보수하기에 좋다 이러던데 MSA를 말하는줄?
잘 묶으면 붙이기는 쉽고 나누기는 쉽지않음 침대를 [침대] 자체로 묶는거랑, [베개], [프레임], [매트리스]로 분리해서 하는거랑은 수리, 조립, 확장 등등 전자 보다는 후자쪽이 유지보수 하기 좋은것 처럼 프로그램도 후자처럼 묶어서 편하게 유지보수 하는 개념임 확장, 수정, 개선 등등 하기 편하게 하는거임
베개도 -> [피], [속] 이렇게 나눌 수 있고, 근데 이 이하로는 나누기가 쉽지 않잖아? 대신 [속], [피]는 이걸 이불의 [속] 이불의 [피] 이렇게 쓸 수도 있어서 재사용은 가능 대신 나누는건 쉽지않음.. MSA도 마찬가지로 결제시스템, 검색시스템 이렇게 나누는 거임 물론 나누는 크기는 시스템이나 설계에 맡게 잘 하는게 개발자의 몫이지..
잘 묶는다면 붙이기 쉬워서 유지보수하기 쉽다는 것도 있긴함. 하지만 그건 일부에 불과함. 거기서 더 나아가 붙이기 쉬운 객체라는 게 무엇일까?라는 의문을 가져야 됨. 개인적으로 이 상태는 한마디로 말하자면 객체가 인터페이스만을 제공하고 내부의 코드 변화가 외부로 거의 전파되지 않는다는 것을 의미한다고 생각함. 즉 비즈니스 로직과 같은 처리가 내부에서 이루어지고 외부에서는 요청을 때리거나 응답을 받아먹기만 하면 된다는 거. 이러면 사이드 이펙트가 최소화 돼서 코드 조금만 바꿨다고 이 코드 저 코드 바꿀 필요가 없어짐. 그래서 전체 코드 베이스에서 특정 부분만 집중하고 딴 데는 신경 안써도 되니까 유지보수하기 쉽다는 거.
아직 msa언급할때가 아닌것 같음 이건 그냥 서버단 코드 짜다 보면..
다들 msa에 꽂혔네 msa에 대해 물은게 아닌데