조회 테이블 : 도메인 모델에서 누수가 있습니까?

10

회사를 추적하는 시스템을 구축 중입니다. 해당 회사에는 연락처가 있습니다. 이러한 담당자는 종종 청구 / 지불, 판매, 주문 및 고객 지원과 같은 특정 유형의 질문에만 답변하는 전문가입니다.

도메인 기반 디자인과 양파 아키텍처를 사용하여 다음 유형으로 모델링했습니다.

회사
- 연락처가 있습니다
접촉
- 접촉 유형이 있습니다
ContactType (열)
회사 저장소 (인터페이스)
EFCompanyRepository (외부 어셈블리에 정의되어 있으며 EntityFramework를 사용하며 CompanyRepository를 구현 함)

우리 팀은이 응용 프로그램의 데이터베이스를 모델링하는 방법에 대한 의견을 나누었습니다.

A면 : 린 DDDers :

연락처에 유효한 ContactType을 정의하는 것은 도메인의 역할입니다. 알 수없는 ContactType이 저장되지 않았 음을 검증하기 위해 데이터베이스에 테이블을 추가하는 것은 도메인 누출의 징후입니다. 논리가 너무 멀리 퍼져 있습니다.
데이터베이스와 해당 코드에 정적 테이블을 추가하는 것은 낭비입니다. 이 응용 프로그램에서 데이터베이스는 한 가지 문제를 해결합니다. 일을 유지하고 나에게 돌려줍니다. 여분의 테이블과 해당 CRUD 코드를 작성하는 것은 낭비입니다.
지속성 전략을 변경하는 것은 가능한 한 쉬워야합니다. 해당 비즈니스 규칙을 변경할 가능성이 높습니다. SQL Server 비용이 너무 많이 든다고 판단하면 스키마에 넣은 모든 유효성 검사를 다시 작성하지 않아도됩니다.

B면 : 전통 주의자 [아마도 공정한 이름은 아닐 것입니다. DBCentrists?] :

코드를 읽지 않고는 이해할 수없는 데이터를 데이터베이스에 저장하는 것은 좋지 않습니다. 보고서 및 기타 소비자는 값 목록 자체를 반복해야합니다.
필요에 따라 DB 유형 사전을로드하는 코드는별로 없습니다. 걱정하지 마십시오.
이 소스가 데이터가 아닌 코드 인 경우 변경 될 때 간단한 SQL 스크립트 대신 비트를 배포해야합니다.

어느 쪽도 옳고 그른 것은 아니지만, 초기 개발, 버그 등의 개발 시간을 세어 장기적으로는 더 효율적일 수 있습니다. 어느 쪽이 좋습니까? 이 스타일의 코드를 작성하는 다른 팀은 무엇을합니까?

domain-driven-design domain-model onion-architecture

— 드류
소스

데이터베이스에 조회 테이블이 있고 응용 프로그램 코드의 조회 테이블을 기반으로 열거 형을 생성하는 코드 (.NET의 T4 템플릿)를 선호합니다.

— 프로그래머

@JasonHolland T4 템플릿이 실제로 쿼리를 수행합니까? 그렇지 않으면 예상 이름으로 빈 열거 형 이상을 생성하는 방법을 잘 모르겠습니다.

— Drew

2

예, 쿼리를 수행합니다. developerhandbook.com/c-sharp/t4-templates-for-lookup-tables 및 erraticdev.blogspot.com/2011/01/…를

— 프로그래머

정적 값이있는 테이블의 경우 얼마나 많은 CRUD 코드를 작성해야합니까? 스크립트를 작성하고 완료하십시오.

— JeffO

2

'보고에 의미가 없습니다.'에 대한 전통적인 CRUD의 주장은 시작이 아닙니다. 시스템이 가지고있는 다른 책임 (즉,보고)을 소개하자마자 적절하게 처리해야하는 비즈니스 요구 사항을 찾았습니다. 데이터베이스는 애플리케이션 자체의 보호 된 상태를 저장하고로드합니다. 이를보고하면 응용 프로그램과 보고서를 필요로하는 사람들 사이에 연결이 만들어집니다. DDD에 관한 것이면 이러한 컨텍스트를 분리하는 것입니다.

— Matt

4

DDD 및 양파 아키텍처를 채택하여 데이터베이스가 도메인 모델에 이어 결정됩니다. 즉, 모델 이외의 데이터베이스에서 다른 작업을 수행하는 사람은 없습니다. 전통 주의자들이 그것을 좋아하지 않는다면, 그들은 우선 DDD를 사용하는 것에 반대해야했다.

첫 번째는 분명합니다. 모델에 "룩업 테이블"이 필요합니다. 모델은 서로 다른 유형의 접점을 구별해야합니다. 즉, 모든 유형의 강력한 형식의 목록을 유지합니다. 강력한 유형에서 데이터베이스로 직렬화 된 값으로 맵핑해야합니다. 이 맵핑은 데이터베이스 모듈 내부에있을 수 있습니다. 그러나 가능한 모든 유형의 목록은 여전히 모델에 있습니다. 그리고 모델이 단일 진실 소스라면 데이터베이스 내에있을 수 없습니다. 또는 적어도 모델에서 목록이 변경되면 데이터베이스에서 변경해야합니다. 그리고 엉덩이는 없습니다!

— 크게 기쁘게
소스

2

도메인 개체 가 프로세스 경계 를 넘어 서면 도메인 개체가되지 않습니다 . 데이터베이스가 단지 지속성 저장소 인 경우에도 미래의 비즈니스 요구로 인해 지속 된 히스토리와 일치하지 않는 도마 임 모델이 변경 될 수 있으며 어쨌든 안티 손상 계층이 필요합니다. ....

즉, DBCentrists가 보트를 놓치고 있다고 생각합니다. 도메인 모델러는 지속성 저장소가 필요하다고 말합니다. "보고서 및 기타 소비자"는 의견에서 언급 한 바와 같이 적절한 색인을 가진 항목을 쿼리 할 수있는 것이 필요합니다.

하나의 데이터베이스 에서 이러한 다양한 문제를 모두 지원해야한다는 제약 조건을 누가 도입 했습니까? 다시 밀면 어떻게됩니까?

검색 키워드 : CQRS

— VoiceOfUnreason
소스

1

열거 형을 데이터베이스에 문자열 표현으로 저장하고 조회 테이블을 포함하지 않는 것이 가장 좋습니다.

분명히 단점은 더 많은 디스크 공간을 사용하고 정규화되지 않는다는 것입니다.

플러스 측면은 필드가 db에서 그 의미를 유지한다는 것입니다. 예를 들어 열거 형의 int 값에 해당하는 매직 숫자로 끝나지 않으며 열거 형이 변경 될 때 조회 테이블의 버전 관리를 할 필요가 없습니다.

나는 이것을 DDD 대 Trad 차이로 특성화 할 것인지 확신하지 못한다. 데이터베이스 중심주의 대 코드가 더 좋습니다.

— 이완
소스

데이터베이스 자체는 열거 기능이 일이 궁금

— herzmeister

DB에 달려 있다고 생각합니다 .MSSQL로 모든 종류의 미친 CLR 작업을 수행 할 수 있습니다. 그러나 나는 그런 것들에 관해서는 'DB bad, code good'측면을 확고히하고 있습니다.

— Ewan

@herzmeister <3 PostgreSQL postgresql.org/docs/9.4/static/datatype-enum.html , Ewan DB는 일단 저장 프로 시저를 받아 들인 코드입니다. (PLv8은 훌륭합니다).

— Sirisian

@Sirisian 당신은 그것이 혼합되는 것을 알고 있습니까? 비슷한 질문이 있습니다. "확장됩니까?"

— Ewan

열거 형을 문자열로 바꾸기 위해 크로스 프로덕트를 수행합니까? 아마 아닙니다. 어떻게 구현되는지 잘 모르겠지만 별도의 테이블을 사용하는 것보다 빠릅니다. 그것은 비늘이다. 이것도 발견했습니다 : stackoverflow.com/questions/2318123/… 5 년 후에도 여전히 유효한 평가처럼 보입니다. (PostgreSQL과 밀접하게 연결된 프로그램을 작성하는 경향이 있으므로 모든 기능을 사용하지만 모든 사람이 그렇게 할 수는 없습니다).

— Sirisian

0

관계형 데이터베이스를 사용하는 한 테이블을 적당한 정도로 정규화해야합니다. 정규화는 삽입 및 업데이트 이상을 방지합니다.
one-app <-> one-database 관계는 더 이상 일반적이지 않으며, 여러 앱에서 여러 데이터베이스를 사용할 수 있고 단일 데이터베이스를 여러 앱에서 사용할 수 있으므로 데이터베이스가 참조 무결성을 최대한 강화하는 것이 좋습니다.
RDBMS는 당신의 친구입니다.
대신 키-값 스토리지를 사용하여 코드로 모든 작업을 수행 할 수 있습니다.

— 툴 린즈 코르도바
소스