기본 키가 비즈니스 도메인의 일부가 아님을 해결

거의 모든 상황에서 기본 키는 비즈니스 도메인의 일부가 아닙니다. 물론, UserName사용자 또는 OrderNumber주문에 대해 고유 한 인덱스를 가진 중요한 사용자 대면 객체가 있을 수 있지만 대부분의 경우 도메인 객체를 단일 값 또는 값 세트로 누구에게나 명백하게 식별 할 필요 가 없습니다 . 관리 사용자. 이러한 예외적 인 경우에도, 특히 GUID (Global Unique Identifier) 를 사용하는 경우 기본 키 자체를 노출하는 대신 대체 키를 사용하거나 사용하려고합니다.

따라서 도메인 기반 디자인에 대한 나의 이해가 정확하다면 기본 키 는 노출 될 필요가 없으며 따라서 잘 찢어 져야합니다 . 그들은 추악하고 내 스타일을 경련. 그러나 도메인 모델에 기본 키를 포함하지 않으면 다음과 같은 결과가 발생합니다.

1. 기본적 으로 도메인 모델 조합에서만 파생되는 DTO (데이터 전송 개체) 에는 기본 키가 없습니다.
2. 들어오는 DTO에는 기본 키가 없습니다.

따라서 실제로 순수하게 유지하고 도메인 모델에서 기본 키를 제거하려는 경우 해당 기본 키의 고유 한 인덱스로 모든 요청을 처리 할 수 ​​있도록 준비해야한다고 말하는 것이 안전합니까?

다시 말해서, 다음 중 어떤 솔루션이 도메인 모델에서 PK를 제거한 후 특정 객체를 식별하는 올바른 접근 방법입니까?

1. 다른 속성으로 처리해야하는 객체를 식별 할 수 있음
2. DTO에서 기본 키를 다시 가져옵니다. 즉, 지속성에서 도메인으로 매핑 할 때 PK를 제거한 다음 도메인에서 DTO로 매핑 할 때 PK를 다시 결합합니까?

편집 :이 구체적으로 만들어 봅시다.

내 도메인 모델은 말 VoIPProvider과 같은 필드를 포함 Name, Description, URL, 참고 문헌이 좋아뿐만 아니라 ProviderType, PhysicalAddress등을 Transactions.

이제 권한있는 사용자가 관리 할 수있는 웹 서비스를 만들고 싶다고 가정 해 보겠습니다 VoIPProvider.

이 경우 사용자에게 친숙한 ID는 쓸모가 없습니다. 결국 VoIP 제공 업체는 이름이 컴퓨터와 구별되는 경향이 있고 사업상의 이유로 인간의 의미와는 구별되는 경향이있는 회사입니다. 따라서 VoIPProvider고유가에 의해 완전히 결정 되었다고 말하는 것으로 충분할 수 있습니다 (Name, URL). 이제 PUT api/providers/voip권한있는 사용자가 VoIP공급자 를 업데이트 할 수 있는 방법 이 필요하다고 가정하겠습니다 . 을 (를) 전송합니다. VoIPProviderDTO여기에는 VoIPProvider잠재적으로 일부 평탄화를 포함하여 의 모든 필드를 포함하지만 전부는 아닙니다 . 그러나, 나는 그들의 마음을 읽을 수 없으며, 여전히 우리가 어떤 제공자에 관해 이야기하고 있는지 말해야합니다.

2 (아마도 3) 옵션이있는 것 같습니다.

1. 내 도메인 모델에 기본 키 또는 대체 키를 포함시켜 DTO로 보내거나 그 반대로
2. 다음과 같은 고유 색인을 통해 관심있는 제공자를 식별하십시오. (Name, Url)
3. 지속성 계층에 대한 구현 세부 사항을 노출하지 않는 방식으로 지속성 계층, 도메인 및 DTO 사이에 항상 맵핑 할 수있는 일종의 중간 오브젝트를 도입하십시오 (예 : 도메인에서 DTO로 갈 때 메모리 내 임시 식별자를 도입하여,

이것이 "도메인 주도 디자인"이라는 용어가 발명되지 않은 15 년 이상 이후 우리가이를 해결하는 방법입니다.

• 도메인 모델을 특정 프로그래밍 언어의 데이터베이스 구현 또는 클래스 모델에 매핑 할 때 "관계형 테이블에 매핑 된 각 도메인 개체에 대해 기본 키는"TablenameID "와 같은 간단하고 일관된 규칙이 있습니다.
• 이 기본 키는 완전히 인공적이며 항상 같은 유형이며 비즈니스 의미가 없습니다 -단지 대리 키
• 도메인 모델의 "그래픽 버전"(도메인 전문가와 대화하는 데 사용하는 모델)에는 기본 키가 없습니다. 전문가에게 직접 공개하지는 않지만 실제로 시스템의 코드를 구현하는 사람에게는 공개합니다.

따라서 기술적 인 목적을 위해 기본 키 (예 : 데이터베이스에 대한 관계 매핑)가 필요할 때마다 키를 사용할 수 있지만 "볼"을 원하지 않는 한 추상화 수준을 "도메인 전문가 모델"로 변경하십시오. ". 그리고 "두 가지 모델"(PK가 있고 다른 하나는없는)을 유지할 필요가 없습니다. 대신 PK가없는 모델 만 유지 관리하고 코드 생성기를 사용하여 DB에 대한 DDL을 작성하면 맵핑 규칙에 따라 PK가 자동으로 추가됩니다.

이는 surrogate 외에 추가 "OrderNumber"와 같은 "비즈니스 키"를 추가하는 것을 금지하지 않습니다 OrderID. 기술적으로 이러한 비즈니스 키는 데이터베이스에 매핑 할 때 대체 키가됩니다. 다른 테이블에 대한 참조를 만드는 데 사용하지 말고 가능한 경우 항상 서로 게이트 키를 사용하는 것이 좋습니다.

귀하의 의견에 따르면, 레코드를 식별하기 위해 대리 키를 사용하는 것은 비즈니스 관련 작업 이 아니며 순수하게 기술적 인 작업입니다. 이를 명확하게하기 위해 예제를 살펴보십시오. 추가 고유 제약 조건을 정의하지 않는 한 (name, url)의 조합은 동일하지만 VoIPProviderID는 다른 두 개의 VoIPProvider 객체를 가질 수 있습니다.

고유 인덱스로 많은 객체를 식별 할 수 있어야 하며 기본 키가 무엇인지 (또는 적어도 하나가 있음을 의미 하지는 않음 )

고유 한 인덱스를 사용할 수 있으므로 PK를 대체하지 않고 DB 스키마를 추가로 제한 할 수 있습니다. PK를 노출시키지 않으면 추악하지만 대신 고유 키를 노출하는 경우 실제로 다른 작업을 수행하지는 않습니다. (여기서 PK와 신원 열이 혼합되어 있지 않다고 가정합니다.)

프런트 엔드에 기본 키가 없으면 백엔드가 보내는 내용을 쉽게 알 수있는 방법이 없습니다. 이를 해결하려면 데이터를 구문 분석하는 데 많은 추가 작업이 필요합니다. 이로 인해 성능이 저하되고 모든 항목에 키를 첨부하는 것보다 더 많은 시간과 시간이 소요될 수 있습니다.

예를 들어 앱에서 메시지를 편집하고 싶다고 가정하겠습니다. 앱에서 기본 키를 첨부하지 않고 편집하려는 메시지를 어떻게 알 수 있습니까? 객체 편집은 항상 발생하며 키없이 수행하는 것은 거의 불가능합니다. 그러나 편집하지 않아야 할 객체가있는 경우 키가 산만하다고 생각되면 키를 건너 뛰지 만 기본 키를 사용하면 여기에서 성능을 향상시킬 수 있습니다.

비즈니스와 관련이없는 PK를 사용하는 이유는 시스템이 사용자가 원하는 것을 쉽고 일관되게 결정할 수 있도록하기위한 것입니다.

MessageSender, MessageRecipient, TimeSent (메시지)와 같은 주석으로 답장을 보았습니다. 이러한 방식으로 애매 모호 할 수 있습니다 (예 : 시스템에서 생성 된 메시지가 자주 발생하는 메시지를 트리거하는 경우). 그리고 여기서 MessageSender와 MessageRecipient를 어떻게 확인할 것입니까? FirstName, Lastname, DateOfBirth를 사용하여 유효성을 검사한다고 가정하면 같은 날 같은 이름으로 2 명이 태어난 상황에 처하게됩니다. 이름이라는 메시지가있는 상황에 처하게된다는 것은 말할 것도 없습니다 tacostacostacos-America-1980-Doc Brown-France-1965-23/5/2014-11:43:54.003UTC+200. 그것은 이름의 괴물이며, 당신은 여전히 ​​그 중 하나만 가질 것이라고 보장하지 않습니다.

기본 키를 사용하는 이유는 입력 한 데이터에 관계없이 소프트웨어 수명 기간 동안 고유해야한다는 것을 알고 있기 때문에 예측 가능한 형식이 될 것입니다 (위 키에 대시가 있으면 어떻게되는지) 사용자 이름으로? 전체 시스템이 똥을 흘립니다).

ID를 사용자에게 보여줄 필요는 없습니다. 필요한 경우 URL을 통해 눈에 잘 띄지 않게 숨길 수 있습니다.

PK가 매우 유용한 또 다른 이유는 위의 내용에서 추론 할 수있는 것입니다. PK는 컴퓨터가 사용자 생성 코드를 해석하도록 강제 할 필요가 없도록합니다. 중국어 사용자가 코드를 사용하고 중국어 문자를 많이 입력하면 코드에서 갑자기 이러한 코드를 내부적으로 처리 할 필요는 없지만 시스템에서 생성 한 Guid를 사용할 수 있습니다. 아랍어를 쓰는 아랍어 사용자가있는 경우 시스템은 내부적으로 해당 언어를 처리 할 필요는 없지만 기본적으로 사용자가 있다는 것을 무시할 수 있습니다.

다른 사람들이 말했듯이, Guid는 내부에 고정 된 크기로 저장할 수있는 것입니다. 당신은 당신이 일하는 것을 알고 있으며 보편적으로 사용될 수있는 것입니다. 특정 식별자를 만들어 저장하는 방법에 대한 디자인 규칙을 만들 필요는 없습니다. 시스템에서 이름의 처음 10 글자 만 사용하면 Michael Guggenheimer와 Michael Gugstein간에 차이가 없으며이 두 가지를 혼동 할 것입니다. 임의의 길이로 잘라 내면 혼동 될 수 있습니다. 사용자 입력을 제한하면 사용자 제한에 문제가 생길 수 있습니다.

Dynamics CRM과 같은 기존 시스템을 살펴보면 사용자가 단일 레코드를 호출하기 위해 내부 키 (PK)도 사용합니다. 사용자에게 ID와 관련이없는 쿼리가 있으면 가능한 답변의 배열을 반환하고 사용자가 선택할 수있게합니다. 모호 할 가능성이있는 경우 사용자에게 선택권을 부여합니다.

마지막으로, 모호함을 통한 보안 성도 뛰어납니다. 레코드 ID를 모르는 경우 유일한 옵션은 레코드 ID를 추측하는 것입니다. ID가 추측하기 쉬운 경우 (정보가 공개되어 있기 때문에) 누구나 변경할 수 있습니다. 클래식 CSRF 또는 XSS 방법을 통해 사용자를 변경하도록 유도 할 수도 있습니다. 이제 보안 버전이 라이브 버전을 게시하기 전에 이미 설명하고 완화해야하지만 잠재적 인 악용이 발생하기는 여전히 어렵습니다.

외부 시스템에 대한 식별자를 발급 할 때 데이터베이스 기본 키를 직접 노출시키지 않고 URI 또는 ​​URI와 동일한 속성을 갖는 키 또는 키 세트 만 제공해야합니다 (여기부터 참조). URI 또는 ​​URI와 동일한 속성을 갖는 키 또는 키 세트 (즉, 아래의 URI가 반드시 RFC 3986 URI를 의미하는 것은 아님).

URI는 객체의 기본 키를 포함하거나 포함하지 않을 수 있으며 실제로 대체 키로 구성되거나 구성되지 않을 수 있습니다. 정말 중요하지 않습니다. 중요한 것은 URI를 생성하는 시스템 만이 URI를 분할하거나 결합하여 참조 된 객체가 무엇인지 이해하도록 허용한다는 것입니다. 외부 시스템은 항상 URI를 불투명 식별자로 사용해야합니다. 인간 사용자가 URI의 한 부분이 실제로 데이터베이스 대리 키인지 또는 여러 비즈니스 키로 구성되어 있거나 실제로 해당 값의 base64임을 식별하는 것은 중요하지 않습니다. 이것들은 관련이 없습니다. 중요한 것은 외부 시스템이 식별자가 식별자를 사용한다는 의미를 이해하기 위해 필요하지 않아야한다는 것입니다. 외부 시스템은 식별자 내의 구성 요소를 구문 분석하거나 시스템의 무언가를 참조하기 위해 식별자를 다른 식별자와 결합 할 필요가 없습니다.

GUID를 사용하면이 기준 중 일부를 충족 할 수 있지만 GUID와 같은 식별자는 시스템 내에서도 객체를 역 참조하기 어려울 수 있으므로 GUID와 같이 시스템에도 불투명 한 키는 클라이언트가 실제로 URI / 식별자를 구문 분석하는 경우에만 사용해야합니다. 보안 위험이 있습니다.

VoIP 예제로 돌아가서 VoIP 제공자는 (VoIPProviderID) 또는 (이름, URL) 또는 (GUID)에 의해 고유하게 결정될 수 있다고 가정하십시오. 외부 시스템의 요구가 VoIP 공급자를 업데이트 할 때, 그냥 통과 할 수있는 PUT / 제공 /로-ID / 1234 또는 PUT /provider/foo-voip/bar-domain.com나 PUT /3F2504E0-4F89-41D3-9A0C-0305E82C3301하고 시스템 외부 시스템이 VoIPProvider를 업데이트하고자하는 것을 이해합니다. 이 URI는 시스템에 의해 생성되며 시스템 만이 모든 것이 동일한 것을 의미한다는 것을 이해하면됩니다. 외부 시스템은 URI에있는 모든 것을 기본적으로 a로 처리해야합니다 PUT <whatever>.

서로 다른 스키마를 사용하여 서로 다른 테이블에 다른 VoIP 공급자에 대한 데이터가 있다고 가정합니다 (따라서 완전히 다른 키 집합은 각 VoIP 공급자가 저장된 테이블을 기준으로 각 VoIP 공급자를 식별합니다). URI가 있으면 시스템에서 특정 VoIP 공급자를 식별하는 방법에 관계없이 외부 시스템에서 URI에 균일하게 액세스 할 수 있습니다. 외부 시스템에서는 모두 불투명 포인터입니다.

시스템이 URI를 사용하여 이러한 방식으로 객체를 참조하면 시스템을 구현하는 방법에 대한 유출이 없습니다. URI를 생성하면 클라이언트가 단순히 URI를 다시 전달합니다.

나는이 매우 부정확하고 순진한 진술을 목표로 삼아야 할 것이다.

이 경우 사용자에게 친숙한 ID는 쓸모가 없습니다. 결국 VoIP 제공 업체는 이름이 컴퓨터와 구별되는 경향이 있고, 사업상의 이유로 인간의 의미와는 구별되는 경향이있는 회사입니다.

이름은 자주 변경되므로 키로 끔찍 합니다. 회사는 일생 동안 많은 이름을 가질 수 있으며 , 회사는 직원이 0 명이지만 완전히 다른 자회사에서 직원을 고용하는 모든 고객이있는 특정 세금 목적으로 고유 한 자회사를 만들 수 있습니다.

그런 다음 Apple과 Apple 의 랜드 마크에서 알 수 있듯이 회사 이름이 원격으로 고유하지 않다는 사실을 알게되었습니다 .

좋은 객체 관계형 매퍼 또는 프레임 워크 는 기본 키를 추상화하고이를 보이지 않게해야하지만 거기에 있으며 일반적으로 데이터베이스에서 객체를 고유하게 식별 할 수있는 유일한 방법입니다.

참고로 django 가 이것을 처리 하는 방법을 선호합니다 .

class VoipProvider(models.Model):
    name=fields.TextField()
    address=fields.TextField()

class Customer(models.Model):
    name=fields.TextField()
    address=fields.TextField()
    voipProvider=fields.ForeignKeyField(VoipProvider)

이런 식으로 고객 제공 업체의 세부 정보는 다음을 사용하여 코드로 액세스 할 수 있습니다.

myCustomer.voipProvider.name #returns the name of the customers VOIP Provider.

기본 / 외국 키는 보이지 않지만, 해당 키가 있으며 항목에 액세스하는 데 사용할 수 있지만 추상화되어 있습니다.

우리는 종종 DB의 관점 에서이 문제를 잘못보고 있다고 생각합니다. 오, 자연 키가 없으므로 대리 키를 만들어야합니다. 아니요, 대리 키를 다시 도메인 개체에 노출시킬 수 없습니다.

그러나 비즈니스 (도메인) 개체에 자연 키가없는 경우에는 더 나은 태도를 취하는 경우가 있습니다. 이는 두 가지 비즈니스 영역 문제입니다. 첫째, 데이터베이스가없는 경우에도 상황이 동일해야합니다. 둘째, 우리는 지속성이 도메인에 보이지 않는 추상적 인 아이디어 인 것처럼 가장하려고 노력하지만 실제로는 지속성이 여전히 비즈니스 개념이라는 것입니다. 분명히, 선택된 자연 키가 DB에서 기본 키 (예 : 일부 시스템의 GUID)로 지원되지 않는 문제가 있습니다.이 경우 대리 키를 추가해야합니다.

따라서 고객은 정수 ID를 갖는 매우 유사한 장소에있게되지만 DB에서 도메인으로 유출되어 병이 들지 않는 대신 모든 고객에게 ID, 그리고 당신은 필요에 따라 DB에 그것을 유지하고 있습니다. 예를 들어 고객 ID 이름 변경을 지원하기 위해 대리자를 자유롭게 소개 할 수 있습니다.

이 방법은 또한 도메인 객체가 지속성 계층에 도달하고 ID가없는 경우 일종의 값 객체 일 수 있으므로 ID가 필요하지 않음을 의미합니다.