도메인 기반 디자인은 안티 -SQL 패턴입니까?

나는 도메인 기반 디자인 (DDD)에 뛰어 들고 있으며 더 깊이 들어가면서 얻을 수없는 것이 있습니다. 내가 이해하는 것처럼 주요 요점은 도메인 로직 (Business Logic)을 인프라 (DB, 파일 시스템 등)에서 분리하는 것입니다.

내가 궁금한 것은 Material Resource Calculation Query와 같은 매우 복잡한 쿼리가있을 때 어떻게됩니까? 그런 종류의 쿼리에서는 SQL이 설계된 종류의 무거운 집합 작업을 사용합니다. 도메인 계층 내에서 이러한 계산을 수행하고 많은 세트로 작업하는 것은 SQL 기술을 버리는 것과 같습니다.

DDD 패턴은 도메인 계층을 변경하지 않고 MongoDB에 SQL Server와 같은 동일한 기능이 없다는 것을 알기 때문에 인프라에서 이러한 계산을 수행 할 수도 없습니다.

이것이 DDD 패턴의 함정입니까?

요즘에는 읽기 (쿼리)가 쓰기 (명령)와 다르게 처리되는 것을 볼 수 있습니다. 복잡한 쿼리가있는 시스템에서는 쿼리 자체가 도메인 모델을 통과 할 가능성이 거의 없습니다 (주로 쓰기 일관성 유지를 담당 함 ).

우리는 SQL 인 SQL을 렌더링해야한다는 것이 옳습니다. 따라서 읽기 주변에 최적화 된 데이터 모델을 설계하고 해당 데이터 모델의 쿼리는 일반적으로 도메인 모델을 포함하지 않는 코드 경로를 사용합니다 (일부 입력 유효성 검사를 제외 하고 쿼리의 매개 변수를 보장 함) 합리적).

내가 이해하는 것처럼 주요 요점은 도메인 로직 (Business Logic)을 인프라 (DB, 파일 시스템 등)에서 분리하는 것입니다.

이것은 오해의 기초입니다. DDD의 목적은 "이것은 SQL 서버에 있으므로 BL이 아니어야합니다."와 같이 하드 라인을 따라 사물을 분리하는 것이 아니라 DDD의 목적은 도메인을 분리하고 사이에 장벽을 만드는 것입니다. 도메인 의 내부를 다른 도메인의 내부와 완전히 분리 할 수 있으며 도메인간에 공유 외부를 정의 할 수 있습니다.

"SQL에 있음"을 BL / DL의 장벽으로 생각하지 마십시오. 대신 "이것은 내부 영역의 끝이다"를 장벽으로 생각하십시오.

각 도메인에는 다른 모든 도메인 에서 작동 할 수있는 외부 API가 있어야 합니다. 데이터 스토리지 계층 의 경우 데이터 스토리지 계층에 대해 CRUD (읽기 / 쓰기) 작업이 있어야합니다. 이 수단의 SQL 자체가 정말 장벽없는의 VIEW및 PROCEDURE구성 요소입니다. : 당신은 테이블에서 직접 읽어 본 적이해야 외부 소비자로, 우리는 걱정하지 말아야한다는 DDD는 우리에게 구현 세부입니다.

귀하의 예를 고려하십시오.

내가 궁금한 것은 Material Resource Calculation Query와 같은 매우 복잡한 쿼리가있을 때 어떻게됩니까? 그런 종류의 쿼리에서는 SQL이 설계된 종류의 무거운 집합 작업을 사용합니다.

이것은 정확히 SQL에 있어야하는 것이며 DDD를 위반하지 않습니다. 그건 우리가 DDD를 만들 었는지 . SQL에서 계산 하면 BL / DL의 일부 가됩니다 . 당신이 할 일은 별도의 뷰 / 저장 프로 시저 / 무엇을 가지고 있고 비즈니스 로직을 외부 API 와 같이 데이터 계층과 분리 하는 것 입니다. 실제로 데이터 계층은 다른 DDD 도메인 계층이어야하며, 데이터 계층에는 다른 도메인 계층과 작업하기위한 자체 추상화가 있습니다.

DDD 패턴은 도메인 계층을 변경하지 않고 MongoDB에 SQL Server와 같은 동일한 기능이 없다는 것을 알기 때문에 인프라에서 이러한 계산을 수행 할 수도 없습니다.

그것은 또 다른 오해입니다 : 그것은 구현 세부 사항이 다른 도메인 계층을 변경하지 않고 내부적으로 변경 될 수 있다고 말합니다 . 전체 인프라를 교체 할 수 있다고 말하는 것은 아닙니다 .

DDD는 잘 정의 된 외부 API로 내부를 숨기는 것에 관한 것입니다. API의 위치는 완전히 다른 질문이며 DDD는 그것을 정의하지 않습니다. 단순히 이러한 API가 존재 한다는 것을 정의 하며 절대로 변경해서는 안됩니다 .

DDD는 MSSQL을 MongoDB로 임시 대체 할 수 있도록 설정되지 않았습니다.이 두 가지는 완전히 다른 인프라 구성 요소입니다.

대신, DDD가 정의한 것에 대한 비유를 사용합시다 : 가스 대 전기 자동차. 두 차량에는 추진력을 생성하기위한 완전히 다른 두 가지 방법이 있지만 온 / 오프, 스로틀 / 브레이크 및 차량을 추진하는 휠과 같은 API가 있습니다. DDD는 자동차의 엔진 (가스 또는 전기)을 교체 할 수 있어야한다고 말합니다. 자동차를 오토바이로 교체 할 수 있다고 말하는 것은 아니며, MSSQL → MongoDB의 효과입니다.

애플리케이션 호스팅 비용을 지불하는 조직이 데이터베이스 계층 라이센스가 너무 비싸다고 결정한 프로젝트를 수행 한 적이 있다면 데이터베이스 / 데이터 스토리지를 쉽게 마이그레이션 할 수 있습니다. 모든 것이 고려되지만 , 이런 일이 발생하지만 자주 발생하지는 않습니다 .

당신은 말하기 위해 두 세계의 최고를 얻을 수 있습니다. 데이터베이스에서 복잡한 기능을 최적화하는 것을 고려하면 인터페이스를 사용하여 대체 계산 구현을 삽입 할 수 있습니다. 문제는 여러 위치에서 논리를 유지해야한다는 것입니다.

건축 패턴에서 벗어남

패턴을 순전히 구현하거나 일부 영역을 벗어나는 데 어려움을 겪게되면 결정해야합니다. 패턴은 단순히 프로젝트를 구성하는 데 도움이되는 일을하는 템플릿 화 된 방법입니다. 이 시점에서 다음을 평가하는 데 시간이 걸립니다.

• 이것이 올바른 패턴입니까? (많은 시간이지만 때로는 때로는 적합하지 않습니다)
• 이 방법으로 벗어나야합니까?
• 내가 지금까지 얼마나 멀리 벗어 났습니까?

일부 아키텍처 패턴은 응용 프로그램의 80-90 %에 적합하지만 나머지 비트에는 그다지 적합하지 않습니다. 규정 된 패턴에서 가끔 벗어나는 것은 성능 또는 물류상의 이유로 유용합니다.

그러나 누적 편차가 응용 프로그램 아키텍처의 20 % 이상을 차지할 경우 적합하지 않을 수 있습니다.

아키텍처를 계속 사용하기로 선택한 경우, 선호하는 방식으로 문서화 된 작업 방식에서 벗어난 위치와 이유를 문서화하십시오. 팀에 새로운 열정을 가진 멤버가 생기면 성과 측정 및 정당성이 포함 된 해당 문서를 가리킬 수 있습니다. 이렇게하면 "문제"를 해결하기 위해 반복 요청이 발생할 가능성이 줄어 듭니다. 이 문서는 만연한 편차를 줄이는 데 도움이 될 것입니다.

SQL에 능숙한 세트 조작 로직은 DDD와 아무런 문제없이 통합 될 수 있습니다.

예를 들어 유형별 총 제품 수에 대한 집계 값을 알아야한다고 가정 해보십시오. SQL에서 실행하기 쉽지만 모든 제품을 메모리에로드하고 모두 추가하면 느려집니다.

새로운 도메인 객체를 소개합니다.

ProductInventory
{
    ProductType
    TotalCount
    DateTimeTaken
}

내 저장소의 방법

ProductRepository
{
    List<ProductInventory> TakeInventory(DateTime asOfDate) {...}
}

물론, 현재 특정 능력을 가진 DB에 의존하고 있습니다. 그러나 나는 여전히 기술적으로 분리되어 있으며 논리가 단순하다면 '비즈니스 논리'가 아니라고 주장 할 수 있습니다.

이 딜레마를 해결하는 가능한 방법 중 하나는 SQL을 어셈블리 언어로 생각하는 것입니다. / C ++ / Golang / Rust 컴파일러는 원하는 기계어 코드를 생성하기 위해 고급 언어로 코드를 변경할 수없는 경우 어셈블리에서 작은 스 니펫을 작성할 수도 있습니다.

마찬가지로 데이터베이스 및 SQL 영역에서 SQLAlchemy 및 Django ORM for Python, LINQ for .NET 과 같은 다양한 SQL 라이브러리 (일부 ORM ) 는 더 높은 수준의 추상화를 제공하지만 가능한 경우 생성 된 SQL 코드를 사용하여 성능을 달성합니다. 또한 더 최적화 된 DB 관련 SQL을 사용하는 일부 작업으로 인해 Postgres 및 MySQL과 같이 다른 성능을 가진 사용 된 DB에 대한 이식성을 제공합니다.

또한 고급 언어와 마찬가지로 위에서 언급 한 SQL 라이브러리로 수행 한 쿼리를 다시 정렬하더라도 원하는 효율성을 달성 할 수 있도록 SQL이 작동하는 방식을 이해하는 것이 중요합니다.

추신 : 나는 이것을 주석으로 만들고 싶지만 그것에 대한 명성이 충분하지 않습니다.

평소와 같이, 이것은 여러 가지 요인에 의존하는 것들 중 하나입니다. SQL로 할 수있는 일이 많다는 것은 사실입니다. 또한이를 사용하는 데 어려움이 있으며 관계형 데이터베이스의 일부 실제적인 한계가 있습니다.

Jared Goguen이 주석에서 언급했듯이 SQL은 테스트 및 검증이 매우 어려울 수 있습니다. 이를 일으키는 주요 요인은 일반적으로 구성 요소로 분해 할 수 없다는 것입니다. 실제로는 복잡한 쿼리를 토토에서 고려해야합니다. 또 다른 복잡한 요소는 SQL의 동작과 정확성이 데이터의 구조와 내용에 크게 의존한다는 것입니다. 이는 가능한 모든 시나리오를 테스트하거나 상황을 결정하는 것이 종종 불가능하거나 불가능하다는 것을 의미합니다. SQL 리팩토링 및 데이터베이스 구조 수정도 마찬가지로 문제가됩니다.

SQL에서 멀어지게하는 또 다른 큰 요인은 관계형 데이터베이스가 수직으로 만 확장되는 경향이 있다는 것입니다. 예를 들어, SQL에서 복잡한 계산을 작성하여 SQL Server에서 실행하면 데이터베이스에서 실행됩니다. 이는 모든 작업이 데이터베이스에서 리소스를 사용하고 있음을 의미합니다. SQL에서할수록 메모리와 CPU 측면에서 데이터베이스에 더 많은 리소스가 필요합니다. 다른 시스템에서 이러한 작업을 수행하는 것은 종종 비효율적이지만 이러한 솔루션에 추가 할 수있는 추가 시스템 수에는 실질적인 제한이 없습니다. 이 방법은 몬스터 데이터베이스 서버를 구축하는 것보다 비용이 적게 들고 내결함성이 있습니다.

이러한 문제는 현재 문제에 적용되거나 적용되지 않을 수 있습니다. 사용 가능한 데이터베이스 자원으로 문제점을 해결할 수있는 경우 문제점 공간에 SQL이 적합 할 수 있습니다. 그러나 성장을 고려해야합니다. 오늘은 괜찮을지 모르지만 몇 년 동안 추가 리소스를 추가하는 비용이 문제가 될 수 있습니다.

이것이 DDD 패턴의 함정입니까?

먼저 몇 가지 오해를 정리하겠습니다.

DDD는 패턴이 아닙니다. 그리고 실제로 패턴을 규정하지는 않습니다.

에릭 에반의 DDD 책 서문 은 다음과 같이 말합니다.

주요 소프트웨어 설계자들은 도메인 모델링과 디자인을 20 년 이상 중요한 주제로 인식 해 왔지만 놀랍게도 수행해야 할 작업이나 수행 방법에 대해서는 거의 기록하지 않았습니다. 그것이 명확하게 공식화되지는 않았지만, 철학은 객체 커뮤니티에서 저류로 등장했습니다. 필자는 도메인 중심 디자인이라고 부릅니다.

[...]

성공에 공통적 인 기능은 디자인의 반복을 통해 진화하고 프로젝트 패브릭의 일부가 된 풍부한 도메인 모델이었습니다.

이 책은 디자인 결정을위한 프레임 워크와 도메인 디자인을 논의하기위한 기술 용어를 제공합니다. 그것은 내 통찰력과 경험과 함께 널리 인정되는 모범 사례를 종합 한 것입니다.

따라서 소프트웨어 개발 및 도메인 모델링에 접근하는 방법과 이러한 활동을 지원하는 일부 기술 용어 (다양한 개념과 패턴을 포함하는 단어)입니다. 또한 완전히 새로운 것이 아닙니다.

명심해야 할 또 다른 사항은 도메인 모델이 시스템에서 찾을 수있는 OO 구현 이 아니라는 것입니다. 이는이를 표현하거나 일부를 표현하는 한 가지 방법 일뿐입니다. 도메인 모델은 소프트웨어로 해결하려는 문제에 대해 생각하는 방식 입니다. 그것은 당신이 물건을 이해하고 인식하는 방법입니다. 그것은의 개념 . 그러나 모호한 의미는 아닙니다. 깊고 세련되었으며 열심히 일하고 지식을 수집 한 결과입니다. 시간이 지남에 따라 더 정교 해지고 발전 할 수 있으며 구현 고려 사항이 포함됩니다 (일부는 모델을 제한 할 수 있음). 모든 팀원 이 공유 해야합니다. (및 관련 도메인 전문가) 및 시스템 구현 방식을 추진하여 시스템이이를 반영하도록합니다.

OO 개발자는 일반적으로 OO 언어로 모델을 표현하는 것이 더 좋을 수도 있지만 OOP는 많은 도메인 개념의 표현을 더 잘 지원할 수 있지만 그에 대한 것은 본질적으로 프로 SQL 또는 안티 SQL이 아닙니다. 그러나 때로는 모델의 일부가 다른 패러다임으로 표현되어야합니다.

내가 궁금한 것은 매우 복잡한 쿼리가있을 때 어떻게됩니까 [...]?

일반적으로 여기에는 두 가지 시나리오가 있습니다.

첫 번째 경우, 도메인의 일부 측면에는 실제로 복잡한 쿼리가 필요하며 해당 측면은 SQL / 관계형 패러다임에 가장 잘 표현 될 수 있으므로 작업에 적합한 도구를 사용하십시오. 도메인 사고와 개념 전달에 사용되는 언어의 측면을 반영하십시오. 도메인이 복잡한 경우, 이는 고유 한 컨텍스트가있는 하위 도메인의 일부일 수 있습니다.

다른 시나리오는 SQL로 무언가를 표현해야한다는 인식이 제약 된 사고의 결과라는 것입니다. 개인이나 팀이 항상 데이터베이스 지향적 사고를한다면 관성으로 인해 다른 방식으로 접근하는 것이 어려울 수 있습니다. 이것은 구식 방법이 새로운 요구를 충족시키지 못할 때 문제가되며, 즉시 다른 사고가 필요합니다. 디자인에 대한 접근 방식 인 DDD는 부분적으로 도메인에 대한 지식을 수집하고 추출하여 상자에서 벗어날 수있는 방법에 관한 것입니다. 그러나 모든 사람들은이 책의 그 부분을 무시하는 것 같으며 기술적 인 어휘와 패턴 중 일부에 중점을 둡니다.

관계형 데이터 모델은 데이터를 정규화하고 파일 시스템에 효과적으로 저장할 수있는 가능성을 제공했기 때문에 메모리가 비쌀 때 Sequel이 인기를 얻었습니다.

메모리는 상대적으로 저렴하므로 정규화를 건너 뛰고 사용하는 형식으로 저장하거나 속도를 위해 동일한 데이터를 많이 복제 할 수 있습니다.

데이터베이스를 파일 시스템에 데이터를 저장할 책임이있는 간단한 IO 장치로 간주하십시오. 예, SQL 쿼리에 작성된 중요한 비즈니스 논리를 가진 많은 응용 프로그램을 작성했기 때문에 상상하기 어렵다는 것을 알고 있습니다. 그러나 SQL Server를 상상해보십시오. 다른 프린터 일뿐입니다.

프린터에서 PDF 생성기를 내장하거나 프린터에서 인쇄 된 모든 판매 주문에 대한 로그 페이지를 인쇄하는 트리거를 추가 하시겠습니까?

우리는 응용 프로그램이 특정 장치 유형에 연결되기를 원하지 않기 때문에 대답이 아니요라고 가정합니다 (이러한 아이디어의 효율성에 대해서도 이야기하지 않음)

70 년대에서 90 년대에 SQL 데이터베이스가 효율적 이었습니까? 확실하지 않은 일부 시나리오에서는 비동기 데이터 쿼리가 SQL 쿼리의 여러 조인보다 필요한 데이터를 빠르게 반환합니다.

SQL은 복잡한 쿼리를 위해 설계된 것이 아니라 효율적인 방식으로 데이터를 저장 한 다음 저장된 데이터를 쿼리하기위한 인터페이스 / 언어를 제공하도록 설계되었습니다.

복잡한 쿼리로 관계형 데이터 모델을 중심으로 응용 프로그램을 작성하는 것은 데이터베이스 엔진의 남용이라고 말합니다. 물론 데이터베이스 엔진 공급자는 비즈니스를 제품에 긴밀하게 연결할 때 행복합니다. 더 강력한 기능을 제공하는 더 많은 기능을 제공하는 것이 행복 할 것입니다.