클린 아키텍처와 헥사고날 아키텍처 질문

오호! 그러면 어떻게보면 개발자 즉, 자기 자신이나 우리 팀이 비즈니스에 집중할 수 있는 구조가 좋은 아키텍처일 수 있겠네요?ㅎㅎ

DDD 현실적 적용

어쩌면, 핵심 도메인, 일반 도메인, 지원 도메인 용어보다 어떤 영역을 자체 개발하고, 어떤 영역을 솔루션으로 개발하고, 어떤 영역을 외주로 개발할 것인지 판단하는게 중요하고, 그리고 그렇게 나누는 기준에 대한 해답은 도메인 자체, 회사 사정, 개발팀 사정에서 찾을 수 있겠네요?ㅎㅎ

DDD 현실적 적용

그러면, 회사 프로젝트에 DDD를 적용하고 싶다고 했을 때, 프로젝트 에서 따로 독립적으로 바운디드 컨텍스트를 만들어 낼만한 도메인 또는 특정 기능을 발견해서 바운디드 컨텍스트를 만들어서 그 부분만 Aggregate 등으로 전술적 설계를 한다고 하면, DDD 했다고 볼 수 있는건가요?어쩌면, DDD를 잘한다고 하는 것은 진흙덩어리에서 독립적으로 떼어낼 수 있는 부분을 가시 바르듯 잘 발라내는 것도 중요한 역량이겠네요?

영속성 전이 관련해서 궁금한 점이 있습니다.

제가 좀더 구체적으로 질문을 드렸어야 했는데ㅠㅠ부모(Parent)와 자식(Child)이 양방향 관계일 때, cascade를 persist로 설정해주면, 아래에서 연관관계 맺어주는 코드가 없어도, 부모 엔티티를 저장할 때 자식 엔티티도 함께 저장되는 건가요?Child child1 = new Child(); Child child2 = new Child(); Parent parent = new Parent(); // -- 연관관계 맺어주는 코드 start --child1.setParent(parent); child2.setParent(parent); parent.getChildren().add(child1); parent.getChildren().add(child2); // -- 연관관계 맺어주는 코드 end --- em.persist(parent);

도메인설계 관련 질문드립니다 !!

영한님 답변을 보고 한가지 궁금한 점이 있습니다.애그리거트내에 여러 엔티티와 여러 값 객체로 이루어질 수 있으나, 애그리거트는 작은 단위로 만드는게 좋아서,하나의 애그리거트에 여러 엔티티보다 하나의 엔티티로 만드는 것을 추천하시나요?

orphanRemoval = false 설정시 질문

정리하면, orphanRemoval=false로 하면, 애플리케이션에서 자식 제거 코드를 작성해도, DB에서는 제거되지 않는다. 다만, CASCADE 가 걸려 있다면, orphanRemoval=false이더라도, DB에서 부모와 같이 자식도 제거되는 걸로 이해하면 될까요?

Facade 클래스에대 설명이 부족해요 ㅠㅠ

답변 감사합니다! 저도 궁금했는데, 덕분에 알게 되었네요!여기서, 더 궁금한 점은 다른 디자인 패턴도 있는데, 왜 퍼사트 패턴을 사용하셨는지 궁금합니다.