데이터베이스에서 도메인 논리의 시대는 끝났습니까? [닫은]

최근 에 데이터베이스에 도메인 논리에 대한 사례가 여전히 있다고 2016 년부터이 의견 을 우연히 발견 했습니다.

나는 이것이 완전히 쓸모 없다고 생각했다. 나는 그 남자가 아직도 90 년대에 살고 있는지 궁금하다. 그렇지 않으면 이것이 사실 일 수있다. 레거시 시스템은 따로 보관하십시오.

보안 요구 사항으로 인해 데이터베이스에 도메인 논리를 갖는 것은 어떻습니까? 정말해야 할 일입니까?

database

— 추신
소스

실제로 그 기사를 완전히 읽었습니까? 저자는 자신의 요점을 명확하게 밝히고 BL에서 어떤 부분이 데이터베이스에 가장 적합하고 어떤 부분에 적합하지 않은지 설명합니다. 그렇다면이 기사에서 정확히 어떤 어려움을 겪고 있습니까?

— Doc Brown

예, 2009 년 2 월 18 일에 문을 닫았으며 이제는 거짓입니다.

— Michael Durrant

궁금합니다. 나는이 사람을 읽고 많은 SQL 예제 (Oracle에 강력하게 묶여 있음)를 제공했으며 고객이 나에게 말하는 것을 기억하지 못했습니다 .PRE 환경에 대한 Oracle의 라이센스를 구입하는 것을 잊었습니다. PRO에는 있지만 PRE에는 없습니다. 시니가 오라클의 기능을 모두가 지금 어디로 가는지 당신은 ... 나는 그 남자에게 묻습니다하면서 ... 조금을 위해, PRO에 PRE와 오라클의 MySQL의에 대해, 응용 프로그램을 배포해야합니다 문제는 여기에 이유가 그 것이었다 ( 나는 건축가가 Orm 대신 네이티브 Sql-Row 매핑 방법을 사용하기로 결정했지만 여전히 DB 공급자에 고정되는 문제에 가깝습니다) .

— Laiv

@Laiv : 그것은 미쳤으며, ORM이나 다른 추상화의 양은 당신을 구할 수 없습니다. 기본적으로 이러한 설정으로 테스트되지 않은 코드를 프로덕션에 배포합니다.

— JacquesB

"데이터베이스에서 도메인 로직의 시대는 끝났습니까?" 신이시길 바래요

— lunchmeat317

답변:

오늘날 프로그래머들은 다른 사람들이 자신의 블로그에서 쓴 생각을 읽을 때 매우 독단적으로 생각하는 것 같습니다.

예를 들어 Bob Martin의 Clean Coding 블로그를 보자. 일반적인 관찰로서, 나는 Bob Martin의 글이 아주 명쾌하고 명쾌하다는 것을 알게 되었기 때문에 사람들이 SOLID 원칙과 같이 자신이 쓴 것들에 끊임없이 혼란스러워하고 있다는 사실에 당황했습니다. 그들은 "단일 책임"이 무엇인지, 또는 일부 클래스가 왜 Liskov의 원칙을 위반하는지에 매달렸다. 아마도 그들이해야 할 일이 단순히 더 나은 코드를 작성하려고 노력하고, 먼저 경험을 쌓기 위해 노력하는 것입니다. 블로그에는 컨텍스트가 있습니다.

기본적으로 당신이 말하는 것은 데이터베이스에 테이블과 데이터가 포함되어 있어야한다는 것입니다. 그러나 데이터베이스는 데이터베이스가 잘하는 특정 작업을 수행하는 데 고유합니다.

이 기사에는 다음과 같은 것들이 있습니다.

데이터 무결성 및 유효성 검사 (예 : null 및 고유 제약 조건)
행 수준 보안
저장 프로 시저를 사용하여 API 작성
잔액 계산
데이터베이스 질문 (예 : 쿼리 및보고)
N + 1과 같은 ORM 문제 방지

데이터베이스에 넣기에 적합한 것. 나는 그에게 동의합니다.

비즈니스 로직을 일반적으로 데이터베이스에 두지 않는 이유 :

공급 업체 잠금
데이터베이스가 중앙 기관이 아닙니다
당신의 팀은 관계 적으로 생각하지 않습니다
열악한 툴링.

그러나 이러한 것들은 일반적으로 데이터베이스에 적합하지 않은 기술, 도구 및 교육에만 적용됩니다.

따라서 소프트웨어 개발의 다른 기술과 마찬가지로 의존합니다. 대안을 평가하고 특정 응용 프로그램에 가장 적합한 조치라고 생각하는 사항에 따라 결정을 내립니다.

— 로버트 하비
소스

아주 좋은 분류 및 질문을 구성하는 더 좋은 방법.

— candied_orange

말과 버기의 시대는 끝났지 만 여전히 버기 채찍을 구입할 수 있습니다.

왜? 자동차가 더 빠르고 저렴하며 유지 관리가 무시 될 때 인도 사회의 방문이 발생하지 않는 이유는 무엇입니까?

때로는 대중적인 이유 외에 다른 일을해야하는 이유가 있기 때문입니다.

당신이 알아야 할 것은 데이터베이스의 도메인 로직이 문제를 일으키는 이유와 누군가가 그로부터 벗어날 수있는 것입니다. 그런 다음 자신의 마음을 구성하십시오.

내 개인적인 견해 :

도메인 로직은 행동에 관한 것입니다. 데이터베이스는 지속성, 관계 및 데이터에 관한 것입니다. 이런 식으로 보면 비즈니스 규칙이 데이터베이스에 없어야합니다.

다른 한편으로, 데이터베이스가 동작을 할 수 없다고 누가 말했습니까? Filemaker를 사용하여 사무실 데이터베이스를 구축했습니다. 사람들은이를 데이터베이스라고하지만 실제로는 전체 애플리케이션 개발 환경이기도합니다. 모든 것이 하나로 완벽하게 통합되어 데이터베이스라고합니다.

지혜는 보통 극단적 인 견해 사이에서 발견됩니다. 의심 할 여지없이 작동 할 수 있습니다. 중간을 찾으려고 할 때 무리를 따라 가고 싶은 유혹이 있습니다. 나는 여기서 그것에 대해주의 할 것입니다.

데이터베이스에서 도메인 논리를 유지하는 시스템이 잘 작동 할 수 있습니다. 데이터베이스에서 도메인 로직을 유지하는 시스템이 잘 작동 할 수 있습니다. 두 곳에서 도메인 로직을 혼합하는 시스템이 저를 지칠 것입니다. 새로운 행동을 어디에 넣을지 모르겠습니다. 오래된 행동을 어디에서 찾을 수 있는지 잘 모르겠습니다.

그래도 동전을 뒤집을 수없고 특정 프로젝트에 대한 복음으로 결정을 내릴 수 없다면. 내가 알 수있는 한, 동전은 다른 사람뿐만 아니라 가장 좋은 것을 알고 있습니다.

— 설탕에 절인 _ 오렌지
소스

당신의 대답은 당신이 OP에 의해 연결된 기사를 보지 않았다고 들리지만 (저는 저자가 옳고 그르다는 것을 말하지는 않습니다), 당신은 그 기사에 묘사 된 견해와 동의하거나 다른 곳을 알려 줄 수 있습니까?

— Doc Brown

@DocBrown 나는 그것을 읽지 않았지만,이 대답은 어쨌든 내가 완전히 동의하는 좋은 것입니다. 또한 인용 된 기사가 아닌 OP의 질문 (마지막 문장)을 다룹니다 .

— qwerty_so

나는 생각하지 않는다 @DocBrown 기사는 읽기 가 인용하는 삼촌 밥 기사 : "안정적인 고 부가가치 비즈니스 규칙이 같은 사용자 인터페이스 및 데이터베이스와 같은 휘발성 낮은 값 모듈에 따라에서 유지 될 수 있기 때문에 플러그인 아키텍처는 매우 강력하다.". Bob 아저씨는이 아이디어에 대해 나보다 더 강한 견해를 가지고 있습니다. 이 기사 체리는 밥의 기사에서 고르고 밥이 자신이 아닌 것을 말하는 것처럼 보입니다.

— candied_orange

비즈니스 계층에서 문제를 해결하는 것이 진정한 성능 저하 요인이었던 경우가있었습니다.

우리의 응용 프로그램 OO 보안 개념은 역할과 그룹으로 구성됩니다. 그리고 둘 다 재귀 구조입니다. 우리는 도메인 객체에 대한 사용자의 권한을 해결하는 저장 프로 시저를 작성했습니다.

데이터베이스 로직으로 대체 할 필요가 거의 없습니다. 그러나이 경우에는 그렇게하기로 결정했습니다. 그러나 항상 고려해야 할 사항 : 추상화를 포기합니다. 데이터베이스에 비즈니스 로직이있는 즉시 지속성 계층을 변경하기가 쉽지 않습니다. 따라서 매우 조심하십시오.

— oopexpert
소스