3

도메인 기반 디자인과 관련하여 질문이 있습니다. 내 응용 프로그램의 사용자 계정/프로필 경계 컨텍스트에는 계정 정보 (ID, 사용자 이름, 암호, 전자 메일, 소금 등) 및 프로필 정보 (성명, 아바타, 생일, 성별 등)가있는 사용자 엔터티가 있습니다. 또한 각 직위에는 고용주 사용자가 있고 각 직무 응용 프로그램에는 신청자 사용자가있는 직책/응용 프로그램에 대한 또 다른 경계가 있습니다.도메인 기반 디자인 : 다른 한정된 컨텍스트에서 사용자 엔터티를 다루는 방법?

사용자가 작업에서 제한된 컨텍스트의 고용주/신청자 사용자가 사용자 계정으로 제한된 컨텍스트에 사용하는 것과 동일한 사용자 엔터티이어야합니까? 또는 고용주 및 신청자에 대해 다른 사용자 유형 엔터티를 설계해야합니까?

보시다시피 계정 한정된 컨텍스트의 ID, 전체 이름, 전자 메일 및 아바타와 같은 정보 만 작업 경계 컨텍스트와 관련이 있습니다. 고용주/신청자가 계정/사용자 프로필에서 동일한 사용자 엔터티를 사용하는 경우 많은 쓸모없는 데이터가로드됩니다 (고용주/신청자의 사용자 암호를 알 필요가 없음). 그러나 다른 엔터티 클래스를 만들면 다른 엔터티 클래스에서 변경 한 내용이 동일한 데이터베이스 테이블의 동일한 데이터를 변경할 수 있으므로 데이터 지속성이 더욱 까다로워집니다.

당신은 어떻게 생각하십니까? 서로 다른 경계가있는 컨텍스트/집합에 대해 하나 또는 모든 사용자 엔터티를 사용해야합니까? 후자가 바람직한 경우 데이터/엔티티 지속성을 사용하여 어떻게 할 수 있습니까?

+0

바운드 컨텍스트가 동일한 DB를 공유합니까? 이상적으로는 안됩니다. 그런 다음 BC가 어떤 데이터를 소유하고 소유 BC가 데이터를 변경하도록 허용하는지 명확히해야합니다. – plalx

+0

나는 당신이하는 말을 이해하지 못합니다. 그것의 동일한 응용 프로그램, 그냥 다른 경계 컨텍스트. 나는 다른 응용 프로그램이 아니라면 항상 같은 DB를 사용합니다. –

+0

BC는 일반적으로 마이크로 서비스로 배포되며 자체 DB가 있습니다. – plalx

답변

1

늙은 질문이고 어쩌면이 딜레마를 풀어봤을 지 모르지만 나는 대답하려고 노력할 것입니다.

당신이 쓴 :

"등의 계정 경계 상황에서 ID, 전체 이름, 이메일, 아바타 등의 정보 만이 작업 경계 맥락에서 관련"

가 그들이 정말 관련이 욥기? 엔티티 (및 더 많은 : 집합과 함께) 모델 데이터가 아니라 모델입니다. Job BC의 어떤 프로세스 또는 유스 케이스에 전체 이름이 필요합니까? 특정 성과 또는 성을 가진 사람을 고용해서는 안된다는 요건이 도메인에 있습니까? 나는 그렇게 생각하지 않는다. 당신이 아마 염두에 두었던 것처럼, 당신은 사람의 정식 명칭이 표시된 몇 개의 스크린을 보여야 만했다고 말했습니다. 그러나 화면 프로세스가 아니며 단지 보고서입니다. 보고서/화면/UI로 모델을 운전해서는 안되며 특정 도메인에있는 프로세스로 모델을 운전해서는 안됩니다.

그래, 어떻게 할 수 있습니까? 분명히 여전히 보고서/화면을 생성해야합니다. 그렇지? 답은 CQRS (https://martinfowler.com/bliki/CQRS.html)가 필요합니다. 명령 스택은 Aggregates 등이 처리하는 프로세스의 모델 일 뿐이므로 빌드 블록은 일부 ORM에 의해 유지됩니다. 그리고 그것들을위한 데이터 모델은 그것들 (빌딩 블록)이 어떻게 생겼는지에 의해 주도 될 것입니다. 복잡한 집계 (예 : 최대 절전 모드)조차도 쉽게 유지할 수있는 일부 ORM을 사용하십시오.

그런 다음 쿼리 스택을 빌드해야합니다. 나는 그것을 달성하는 두 가지 방법을보고, 당신이 같은 DB 스키마에 BC를 가지고 있는지 여부에 달려있다.

두 BC가 동일한 스키마에있는 경우 보고서/화면에 대한 데이터를 구성 할 일부 데이터베이스보기를 사용하십시오. MyBatis 나 Spring JDBC와 같은 복잡한 쿼리 인 ORM (또는 JDBC 분노로 고생하기를 원한다면 평범한 JDBC도 가능)을 위해 정말 빠르고 유연한 방법을 사용하십시오. 이 스택에서 가능한 한 SQL에 가깝게하는 것이 좋다는 것을 알게 될 것이기 때문에 여기에서 Hibernate를 사용하지 마라.데이터 쿼리 추상화는 사용 된 프레임 워크/ORM을 사용하여 화면이 아닌 집계 및 해당 프로세스에 의해 구동되는 데이터 모델의 복잡한 조인을 수행하도록 고민하게됩니다. 또 다른 이유는 일반적인 비즈니스 어플리케이션에서 CQRS로 말하면 DB에 쓰는 것보다 몇 배 더 많은 판독 값이 있기 때문에 명령 스택 사용법보다 쿼리 스택 사용법이 더 많으므로 여기서 빠르게해야합니다.

BC가 서로 다른 스키마에있는 경우 두 스키마를 "병합"하는보고 데이터베이스 (https://martinfowler.com/bliki/ReportingDatabase.html)를 빌드해야합니다. 그런 다음 병합 된 스키마에 대한 뷰를 수행 할 수 있으며 문제는 위의 뷰로 단순화됩니다.

보고 데이터베이스는 다른 확장 가능성을 제공합니다.이 데이터베이스는 읽기 전용이므로 여러 서버간에 쉽게 복제 할 수 있으므로 쿼리 스택 서비스를 곱하여 일부 Load Balancer 뒤에 숨길 수 있습니다.

이메일 주소 속성은 무엇입니까? 고용주 또는 신청자에게 도메인에서 수행 된 일부 작업/프로세스에 대해 통보해야하는 도메인의 유스 케이스가있을 수 있습니다. 이 사용 사례를 처리하는 도메인 서비스 (또는 도메인 이벤트 처리기)는이 특정 사용자 (또는 어딘가에서 처리 될 브로드 캐스트 도메인 이벤트)의 전자 메일에 대해 다른 BC 서비스에 요청해야한다고 생각합니다. 또는 더 나아가서 -이 작업을 또 다른 BC의 일부 알림 서비스에 위임해야합니다. 그리고이 알림 서비스는 계정 BC의 이메일 주소 서비스를 요청합니다.

Bounded Context (유비쿼터스 언어와 함께)는 DDD의 가장 중요한 아이디어입니다. 이것은 모델링하는 동안 Big Ball of Mud를 피하는 강력한 도구입니다. 그리고 실제 도메인에서 바운드 컨텍스트를 결정하는 것은 정말 쉽지 않습니다 :)

+0

이것은 다른 BC의 ID를 가진 "User entity"가 있다는 뜻입니까? – Pepster

+0

@Pepster 일반적으로 : 예 (데이터 관계를 실현하기 위해). 세부 사항 : 작업 BC에는 사용자 엔티티가 없어야합니다. "사용자"는이 BC에 아무런 의미가 없습니다. "직원"과 "고용주"가있을 수 있습니다. 그리고 그들은 계정 BC에서 "사용자"의 ID를 가질 수 있습니다. 데이터를 일치시킵니다. – krzys

관련 문제