Thiết kế hướng tên miền có phải là mẫu chống SQL không?

Tôi đang lặn trong thiết kế điều khiển miền (DDD) và trong khi tôi đi sâu hơn vào nó, có một số điều tôi không nhận được. Theo tôi hiểu, một điểm chính là tách Logic miền (Logic nghiệp vụ) khỏi Cơ sở hạ tầng (DB, Hệ thống tệp, v.v.).

Điều tôi băn khoăn là, điều gì xảy ra khi tôi có các truy vấn rất phức tạp như Truy vấn tính toán tài nguyên vật liệu? Trong loại truy vấn mà bạn làm việc với các hoạt động tập nặng, loại điều mà SQL được thiết kế cho. Thực hiện các tính toán bên trong Lớp Miền và làm việc với rất nhiều bộ trong đó giống như loại bỏ công nghệ SQL.

Thực hiện các tính toán này trong cơ sở hạ tầng cũng không thể xảy ra, vì mẫu DDD cho phép thay đổi cơ sở hạ tầng mà không thay đổi Lớp Miền và biết rằng MongoDB không có các khả năng tương tự như SQL Server, điều đó không thể xảy ra.

Đó có phải là một cạm bẫy của mẫu DDD?

Ngày nay, bạn có thể thấy các lần đọc (truy vấn) được xử lý khác với ghi (lệnh). Trong một hệ thống có truy vấn phức tạp, bản thân truy vấn không có khả năng chuyển qua mô hình miền (chịu trách nhiệm chính cho việc duy trì tính nhất quán của ghi ).

Bạn hoàn toàn đúng khi nói rằng chúng ta nên kết xuất SQL với SQL. Vì vậy, chúng tôi sẽ thiết kế một mô hình dữ liệu được tối ưu hóa xung quanh các lần đọc và một truy vấn của mô hình dữ liệu đó thường sẽ có một đường dẫn mã không bao gồm mô hình miền (ngoại trừ một số xác thực đầu vào - đảm bảo các tham số trong truy vấn đều hợp lý).

Theo tôi hiểu, một điểm chính là tách Logic miền (Logic nghiệp vụ) khỏi Cơ sở hạ tầng (DB, Hệ thống tệp, v.v.).

Đây là nền tảng của sự hiểu lầm: mục đích của DDD không phải là phân tách mọi thứ theo một đường cứng như "đây là trong máy chủ SQL, vì vậy không phải là BL", mục đích của DDD là tách các miền và tạo ra các rào cản giữa chúng cho phép các phần bên trong của một miền tách biệt hoàn toàn với các phần bên trong của một tên miền khác và để xác định các phần bên ngoài được chia sẻ giữa chúng.

Đừng nghĩ rằng "đang ở trong SQL" như là rào cản BL / DL mà không phải như vậy. Thay vào đó, hãy nghĩ rằng "đây là sự kết thúc của miền nội bộ" là rào cản.

Mỗi miền phải có API đối diện bên ngoài cho phép nó hoạt động với tất cả các miền khác : trong trường hợp lớp lưu trữ dữ liệu , nó sẽ có các hành động đọc / ghi (CRUD) cho các đối tượng dữ liệu mà nó lưu trữ. Điều này có nghĩa là chính SQL không thực sự là rào cản, VIEWvà PROCEDUREcác thành phần là. Bạn không bao giờ nên đọc trực tiếp từ bảng: đó là chi tiết triển khai DDD cho chúng ta biết rằng, là một người tiêu dùng bên ngoài, chúng ta không nên lo lắng.

Hãy xem xét ví dụ của bạn:

Điều tôi băn khoăn là, điều gì xảy ra khi tôi có các truy vấn rất phức tạp như Truy vấn tính toán tài nguyên vật liệu? Trong loại truy vấn mà bạn làm việc với các hoạt động tập nặng, loại điều mà SQL được thiết kế cho.

Đây chính xác là những gì nên có trong SQL và đó không phải là vi phạm DDD. Đó là những gì chúng tôi đã tạo ra DDD cho . Với tính toán đó trong SQL, đó trở thành một phần của BL / DL. Những gì bạn sẽ làm là sử dụng một chế độ xem / thủ tục được lưu trữ riêng biệt / những gì bạn có và giữ logic nghiệp vụ tách biệt khỏi lớp dữ liệu, vì đó là API bên ngoài của bạn. Trên thực tế, lớp dữ liệu của bạn phải là một Lớp Miền DDD khác, trong đó lớp dữ liệu của bạn có các tóm tắt riêng để hoạt động với các lớp miền khác.

Thực hiện các tính toán này trong cơ sở hạ tầng cũng không thể xảy ra, vì mẫu DDD cho phép thay đổi cơ sở hạ tầng mà không thay đổi Lớp Miền và biết rằng MongoDB không có các khả năng tương tự như SQL Server, điều đó không thể xảy ra.

Đó là một sự hiểu lầm khác: nó nói chi tiết triển khai trong nội bộ có thể thay đổi mà không thay đổi các lớp miền khác . Nó không nói rằng bạn chỉ có thể thay thế toàn bộ cơ sở hạ tầng.

Một lần nữa, hãy nhớ rằng, DDD là về việc ẩn nội bộ với các API bên ngoài được xác định rõ. Trường hợp các API đó là một câu hỏi hoàn toàn khác và DDD không xác định điều đó. Nó chỉ đơn giản xác định rằng các API này tồn tại và không bao giờ nên thay đổi .

DDD không được thiết lập để cho phép bạn thay thế MSSQL bằng MongoDB, đó là hai thành phần cơ sở hạ tầng hoàn toàn khác nhau.

Thay vào đó, hãy sử dụng một sự tương tự cho những gì DDD định nghĩa: xăng so với ô tô điện. Cả hai phương tiện đều có hai phương pháp hoàn toàn khác nhau để tạo lực đẩy, nhưng chúng có cùng API: bật / tắt, bướm ga / phanh và bánh xe để đẩy xe. DDD nói rằng chúng ta sẽ có thể thay thế động cơ (xăng hoặc điện) trong xe hơi của chúng ta. Điều đó không nói rằng chúng ta có thể thay thế ô tô bằng xe máy và đó chính là MSSQL → MongoDB.

Nếu bạn đã từng tham gia một dự án nơi tổ chức trả tiền để lưu trữ ứng dụng quyết định rằng giấy phép lớp cơ sở dữ liệu quá đắt, bạn sẽ đánh giá cao sự dễ dàng mà bạn có thể di chuyển cơ sở dữ liệu / lưu trữ dữ liệu của mình. Tất cả những điều được xem xét, trong khi điều này xảy ra, nó không xảy ra thường xuyên .

Bạn có thể có được những điều tốt nhất của cả hai thế giới để nói. Nếu bạn coi việc thực hiện các chức năng phức tạp trong cơ sở dữ liệu là tối ưu hóa, thì bạn có thể sử dụng một giao diện để thực hiện phép tính thay thế. Vấn đề là bạn phải duy trì logic ở nhiều vị trí.

Đi chệch khỏi một mô hình kiến ​​trúc

Khi bạn thấy mình bất hòa với việc thực hiện một mô hình hoàn toàn, hoặc đi chệch hướng trong một số lĩnh vực, thì bạn có một quyết định để đưa ra. Một mô hình chỉ đơn giản là một cách tạo khuôn mẫu để làm những việc giúp tổ chức dự án của bạn. Tại thời điểm này cần có thời gian để đánh giá:

• Đây có phải là mô hình đúng? (nhiều lần là như vậy, nhưng đôi khi nó chỉ là một sự phù hợp xấu)
• Tôi có nên đi chệch hướng theo cách này?
• Tôi đã đi chệch bao xa?

Bạn sẽ thấy rằng một số mẫu kiến ​​trúc phù hợp với 80-90% ứng dụng của bạn, nhưng không nhiều cho các bit còn lại. Sự sai lệch thỉnh thoảng từ mẫu quy định là hữu ích cho các lý do hiệu suất hoặc hậu cần.

Tuy nhiên, nếu bạn thấy rằng độ lệch tích lũy của bạn tương đương với hơn 20% kiến ​​trúc ứng dụng của bạn, thì đó có lẽ chỉ là một sự phù hợp xấu.

Nếu bạn chọn tiếp tục với kiến ​​trúc, thì hãy tạo cho mình một tài liệu và tài liệu ở đâu và tại sao bạn đi chệch khỏi cách làm việc quy định. Khi bạn có được một thành viên nhiệt tình mới trong nhóm của mình, bạn có thể chỉ cho họ tài liệu đó bao gồm các phép đo hiệu suất và biện minh. Điều đó sẽ làm giảm khả năng lặp lại các yêu cầu để khắc phục "sự cố". Tài liệu đó cũng sẽ giúp không khuyến khích những sai lệch tràn lan.

Logic thao tác thiết lập mà SQL giỏi có thể được tích hợp với DDD không có vấn đề gì.

Nói ví dụ tôi cần biết một số giá trị tổng hợp, tổng số sản phẩm theo loại. Dễ dàng chạy trong sql, nhưng chậm nếu tôi tải mọi sản phẩm vào bộ nhớ và thêm tất cả chúng lên.

Tôi chỉ đơn giản là giới thiệu một đối tượng Miền mới,

ProductInventory
{
    ProductType
    TotalCount
    DateTimeTaken
}

và một phương thức trên kho lưu trữ của tôi

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

Chắc chắn, có lẽ bây giờ tôi đang dựa vào DB của mình có những khả năng nhất định. Nhưng về mặt kỹ thuật tôi vẫn có sự tách biệt và miễn là logic đơn giản, tôi có thể lập luận rằng đó không phải là 'logic kinh doanh'

Một trong những cách có thể để giải quyết vấn đề nan giải này là nghĩ về SQL như một ngôn ngữ hợp ngữ: bạn hiếm khi, nếu có, mã trực tiếp trong đó, nhưng khi vấn đề về hiệu năng, bạn cần có thể hiểu mã do C tạo ra / C ++ / Golang / Trình biên dịch Rust và thậm chí có thể viết một đoạn nhỏ trong cụm, nếu bạn không thể thay đổi mã bằng ngôn ngữ cấp cao của bạn để tạo mã máy mong muốn.

Tương tự, trong lĩnh vực cơ sở dữ liệu và SQL, các thư viện SQL khác nhau (một số trong đó là ORM ), ví dụ SQLAlchemy và Django ORM cho Python, LINQ cho .NET, cung cấp các bản tóm tắt cấp cao hơn nhưng vẫn sử dụng mã SQL được tạo khi có thể để đạt được hiệu suất. Chúng cũng cung cấp một số tính di động đối với DB được sử dụng, có thể có hiệu suất khác nhau, ví dụ như trên Postgres và MySQL, do một số hoạt động sử dụng một số SQL cụ thể DB tối ưu hơn.

Và cũng giống như với các ngôn ngữ cấp cao, điều quan trọng là phải hiểu cách SQL hoạt động, ngay cả khi chỉ là sắp xếp lại các truy vấn được thực hiện với các thư viện SQL đã đề cập ở trên, để có thể đạt được hiệu quả mong muốn.

Tái bút: Tôi muốn đưa ra nhận xét này nhưng tôi không có đủ danh tiếng cho việc đó.

Như thường lệ, đây là một trong những điều phụ thuộc vào một số yếu tố. Đúng là có rất nhiều thứ bạn có thể làm với SQL. Cũng có những thách thức với việc sử dụng nó và một số hạn chế thực tế của cơ sở dữ liệu quan hệ.

Như Jared Goguen lưu ý trong các bình luận, SQL có thể rất khó kiểm tra và xác minh. Các yếu tố chính dẫn đến điều này là nó không thể (nói chung) bị phân hủy thành các thành phần. Trong thực tế, một truy vấn phức tạp phải được xem xét trong toto. Một yếu tố phức tạp khác là hành vi và tính chính xác của SQL phụ thuộc nhiều vào cấu trúc và nội dung dữ liệu của bạn. Điều này có nghĩa là việc kiểm tra tất cả các kịch bản có thể (hoặc thậm chí xác định chúng là gì) thường không khả thi hoặc không thể. Tái cấu trúc SQL và sửa đổi cấu trúc cơ sở dữ liệu cũng có vấn đề.

Yếu tố lớn khác dẫn đến việc di chuyển khỏi SQL là cơ sở dữ liệu quan hệ có xu hướng chỉ mở rộng theo chiều dọc. Ví dụ: khi bạn xây dựng các phép tính phức tạp trong SQL để chạy trong SQL Server, chúng sẽ thực thi trên cơ sở dữ liệu. Điều đó có nghĩa là tất cả các công việc đó đang sử dụng tài nguyên trên cơ sở dữ liệu. Bạn càng làm nhiều trong SQL, cơ sở dữ liệu của bạn sẽ cần nhiều tài nguyên hơn về bộ nhớ và CPU. Việc thực hiện những điều này trên các hệ thống khác thường kém hiệu quả hơn nhưng không có giới hạn thực tế đối với số lượng máy móc bổ sung mà bạn có thể thêm vào một giải pháp như vậy. Cách tiếp cận này ít tốn kém và chịu nhiều lỗi hơn so với việc xây dựng một máy chủ cơ sở dữ liệu quái vật.

Những vấn đề này có thể hoặc không thể áp dụng cho vấn đề hiện tại. Nếu bạn có thể giải quyết vấn đề của mình bằng các tài nguyên cơ sở dữ liệu có sẵn, có thể SQL sẽ ổn cho không gian vấn đề của bạn. Bạn cần xem xét sự tăng trưởng, tuy nhiên. Hôm nay có thể ổn nhưng vài năm nữa, chi phí bổ sung thêm tài nguyên có thể trở thành một vấn đề.

Đó có phải là một cạm bẫy của mẫu DDD?

Trước tiên hãy để tôi xóa một vài quan niệm sai lầm.

DDD không phải là một mô hình. Và nó không thực sự quy định các mẫu.

Lời nói đầu cho cuốn sách DDD của Eric Evan nêu rõ:

Các nhà thiết kế phần mềm hàng đầu đã công nhận mô hình hóa và thiết kế miền là chủ đề quan trọng trong ít nhất 20 năm, nhưng đáng ngạc nhiên là có rất ít bài viết về những gì cần phải làm hoặc cách thực hiện. Mặc dù nó chưa bao giờ được xây dựng rõ ràng, một triết lý đã nổi lên như một dòng chảy ngầm trong cộng đồng đối tượng, một triết lý mà tôi gọi là thiết kế hướng tên miền.

[...]

Một tính năng phổ biến cho sự thành công là một mô hình miền phong phú phát triển thông qua các bước lặp của thiết kế và trở thành một phần của kết cấu của dự án.

Cuốn sách này cung cấp một khuôn khổ để đưa ra quyết định thiết kế và từ vựng kỹ thuật để thảo luận về thiết kế miền. Nó là tổng hợp của các thực tiễn tốt nhất được chấp nhận rộng rãi cùng với những hiểu biết và kinh nghiệm của riêng tôi.

Vì vậy, đó là một cách để tiếp cận phát triển phần mềm và mô hình hóa miền, cộng với một số từ vựng kỹ thuật hỗ trợ các hoạt động đó (một từ vựng bao gồm các khái niệm và mẫu khác nhau). Nó cũng không phải là một cái gì đó hoàn toàn mới.

Một lưu ý khác là mô hình miền không phải là triển khai OO của mô hình có thể tìm thấy trong hệ thống của bạn - đó chỉ là một cách để thể hiện nó hoặc thể hiện một phần của nó. Mô hình miền là cách bạn nghĩ về vấn đề bạn đang cố gắng giải quyết với phần mềm. Đó là cách bạn hiểu và nhận thức mọi thứ, cách bạn nói về chúng. Đó là khái niệm . Nhưng không phải trong một số ý nghĩa mơ hồ. Nó sâu sắc và tinh tế, và là kết quả của quá trình thu thập kiến ​​thức và làm việc chăm chỉ. Nó được tiếp tục hoàn thiện và có khả năng phát triển theo thời gian, và nó liên quan đến việc xem xét thực hiện (một số trong đó có thể hạn chế mô hình). Nó nên được chia sẻ bởi tất cả các thành viên trong nhóm (và các chuyên gia tên miền có liên quan), và nó sẽ thúc đẩy cách bạn triển khai hệ thống, để hệ thống phản ánh chặt chẽ nó.

Không có gì về điều đó vốn dĩ là chống hoặc SQL, mặc dù các nhà phát triển OO có lẽ nói chung là tốt hơn trong việc thể hiện mô hình bằng các ngôn ngữ OO và biểu thức của nhiều khái niệm miền được OOP hỗ trợ tốt hơn. Nhưng đôi khi các phần của mô hình phải được thể hiện trong một mô hình khác nhau.

Điều tôi băn khoăn là, điều gì xảy ra khi tôi có các truy vấn rất phức tạp [...]?

Vâng, nói chung có hai kịch bản ở đây.

Trong trường hợp đầu tiên, một số khía cạnh của một miền thực sự đòi hỏi một truy vấn phức tạp và có lẽ khía cạnh đó được thể hiện tốt nhất trong mô hình SQL / quan hệ - vì vậy hãy sử dụng công cụ thích hợp cho công việc. Phản ánh những khía cạnh trong suy nghĩ tên miền của bạn và ngôn ngữ được sử dụng trong việc truyền đạt các khái niệm. Nếu tên miền phức tạp, có lẽ đây là một phần của tên miền phụ với bối cảnh giới hạn của chính nó.

Kịch bản khác là nhu cầu nhận thức để diễn đạt một cái gì đó trong SQL là kết quả của suy nghĩ bị hạn chế. Nếu một người hoặc một nhóm luôn được định hướng cơ sở dữ liệu trong suy nghĩ của họ, điều đó có thể gây khó khăn cho họ, chỉ do quán tính, để thấy một cách tiếp cận khác nhau. Điều này trở thành một vấn đề khi cách cũ không đáp ứng được nhu cầu mới và đòi hỏi một số suy nghĩ vượt trội. DDD, như một cách tiếp cận để thiết kế, là một phần về các cách để tìm đường ra khỏi hộp đó bằng cách thu thập và chắt lọc kiến ​​thức về tên miền. Nhưng mọi người dường như bỏ qua phần đó của cuốn sách, và tập trung vào một số từ vựng kỹ thuật và các mẫu được liệt kê.

Phần tiếp theo trở nên phổ biến khi bộ nhớ đắt tiền, bởi vì mô hình dữ liệu quan hệ cung cấp khả năng bình thường hóa dữ liệu của bạn và lưu trữ hiệu quả trong hệ thống tệp.

Bây giờ bộ nhớ tương đối rẻ, vì vậy chúng ta có thể bỏ qua chuẩn hóa và lưu trữ ở định dạng chúng ta sử dụng hoặc thậm chí sao chép nhiều dữ liệu giống nhau vì tốc độ.

Hãy coi cơ sở dữ liệu là thiết bị IO đơn giản , có trách nhiệm lưu trữ dữ liệu trong hệ thống tệp - vâng tôi biết rất khó để tưởng tượng nó, bởi vì chúng tôi đã viết rất nhiều ứng dụng với logic nghiệp vụ quan trọng được viết vào các truy vấn SQL - nhưng chỉ cần thử tưởng tượng SQL Server đó chỉ là một máy in khác.

Bạn có nhúng trình tạo PDF vào trình điều khiển máy in hoặc thêm trình kích hoạt sẽ in trang nhật ký cho mỗi đơn đặt hàng được in ra từ máy in của chúng tôi không?

Tôi cho rằng câu trả lời sẽ là không, vì chúng tôi không muốn ứng dụng của mình được kết hợp với loại thiết bị cụ thể (thậm chí không nói về hiệu quả của ý tưởng đó)

Bây giờ cơ sở dữ liệu SQL của thập niên 70 có hiệu quả không? - Không chắc chắn, trong một số trường hợp truy vấn dữ liệu không đồng bộ sẽ trả về dữ liệu được yêu cầu nhanh hơn nhiều lần tham gia trong truy vấn SQL.

SQL không được thiết kế cho các truy vấn phức tạp, nó được thiết kế để lưu trữ dữ liệu theo cách hiệu quả và sau đó cung cấp giao diện / ngôn ngữ để truy vấn dữ liệu được lưu trữ.

Tôi muốn nói rằng việc xây dựng ứng dụng của bạn xung quanh mô hình dữ liệu quan hệ với các truy vấn phức tạp là lạm dụng công cụ cơ sở dữ liệu. Tất nhiên các nhà cung cấp công cụ cơ sở dữ liệu rất vui khi bạn kết hợp chặt chẽ doanh nghiệp của mình với sản phẩm của họ - họ sẽ rất vui khi cung cấp nhiều tính năng giúp ràng buộc này mạnh mẽ hơn.