데이터베이스의 도메인 모델이 지속 가능한 솔루션 일 수 있습니까?

방금 Microsoft 기술 기반의 중소 규모 회사의 데이터베이스 개발자로 새로운 직책을 시작했습니다. 모범 사례, 디자인 패턴, 테스트 및 프로젝트 관리와 관련하여 학교에서 배운 것과 얼마나 많은 관행이 벗어 났는지 일찍 알았습니다.

가장 큰 문제는 주 데이터베이스 개발자 (이하 "John")가 모델 스키마를 데이터베이스에 유지하는 방법입니다. 우리는 3 개의 "매직"테이블을 가짐으로써이를 수행합니다. 하나는 데이터베이스 스키마, 하나는 테이블 및 하나는 열입니다.

" 테이블 "테이블에 레코드를 삽입하면 데이터베이스 트리거를 통해 실제 해당 테이블이 생성됩니다. " Rows "테이블에 행을 삽입하면 해당 행으로 참조 된 테이블이 업데이트됩니다. 이것들은 C # 모델을 생성하기 위해 직접 만든 C # 프로그램에 의해 읽혀지며 컨트롤러와 외부의 프론트 엔드 개발자가 사용합니다.

이 외에도 대부분의 개발은 ASP.NET MVC 프레임 워크 에 따라 수행됩니다 .

이 접근법에는 몇 가지 결함이 있습니다.

• 우리는 그를 ORM을 유지할 필요가 있으며, 그렇게 할 시간이 거의 없습니다 (직업 보안이 좋습니다!)
• "테이블"및 "행"테이블에 대한 트리거에 결함이 있습니다. 테이블 업데이트 나 검사 제한 또는 "고급"기능을 지원하지 않습니다. 확실히 개선 할 수는 있지만 아직이 방법이 확실하지 않습니다.
• 데이터베이스에 프로그래밍 논리를 유지하는 것은 이상하고 제한적입니다 (C #을 통해 모델을 확장 할 수는 있지만).
• 그의 C # 모델 생성기는 3 명 중 한 사람 (수동으로) 중 하나가 수동으로 실행해야하며 아직 자동화 된 빌드 프로세스에 포함될 정도로 성숙하지 않습니다.

몇몇 사람들은 Entity Framework 와 같은 테스트를 거친 제품에서 위상을 제안 했지만 비즈니스 계층을 코드 계층에 유지하는 것이 소규모 응용 프로그램 및 스타트 업을위한 부트 스트랩 프로젝트에만 적합하다는 결론을 내 렸습니다.

이 게시물은 의견이 많은 토론처럼 보일 수있는 내용으로 이끌고 있지만 이것이 내 의도는 아닙니다. 우리의 건축 접근법에 관한 설명을 원합니다.

도메인 모델을 데이터베이스에 유지하는 것이 성장하는 회사에게 지속 가능한 솔루션 일 수 있습니까?

내부 플랫폼을 설명하고 있습니다.

내부 플랫폼의 문제점은 수십 년 동안 진화와 노력을 통해 연마되고 완성되었지만 플랫폼을 재창조 한 플랫폼 또는 기술 (이 경우 관계형 데이터베이스)의 모든 메커니즘을 재창조한다는 것입니다. 보다 전통적인 디자인을 선택하는 사람들이 이용할 수있는 모든 최적화를 무시하고 미래의 복잡성과 어려움을 위해 초기 단순성과 우아함을 거래합니다.

즉,이 프로세스의 최종 결과물이 실제 비즈니스 도메인 객체를 모델링하는 실제 테이블과 실제 클래스 라면 툴의 미숙함을 제외하고는이 접근 방식에 큰 해를 끼치 지 않습니다. 실제로 Stack Exchange는 자체 자체 개발 한 ORM을 사용하므로 문제가 해결 된 것 같습니다. 따라서 이러한 종류의 "코티지"접근 방식이 효과적이라는 것을 알고 있습니다.

"table-first"접근 방식을 사용하는 대부분의 ORM은 단순히 데이터베이스에서 테이블 구조를보고 클래스를 작성합니다. 친구가 만든 "테이블"및 "행" 테이블은 가장 현대적인 관계형 데이터베이스 시스템의 시스템 테이블에 이미 존재 하는 메타 데이터 일뿐 입니다.

또한 읽기
은 "비전"프로젝트, 내부 플랫폼 효과에 대한 경계의 이야기
_{(당신은 "비전 소개"프리앰블을 건너 뛰고 부제목에서 읽기 시작 할 수 있습니다)}