Giải quyết thực tế là các khóa chính không phải là một phần của lĩnh vực kinh doanh của bạn

Trong hầu hết mọi trường hợp, khóa chính không phải là một phần của miền doanh nghiệp của bạn. Chắc chắn, bạn có thể có một số đối tượng quan trọng đối với người dùng với các chỉ số duy nhất ( UserNamecho người dùng hoặc OrderNumbercho đơn đặt hàng) nhưng trong hầu hết các trường hợp, không có doanh nghiệp nào cần phải xác định công khai các đối tượng miền bằng một giá trị hoặc tập hợp giá trị cho bất kỳ ai, nhưng có lẽ là một người dùng hành chính. Ngay cả trong những trường hợp đặc biệt đó, đặc biệt nếu bạn đang sử dụng số nhận dạng duy nhất toàn cầu (GUID) , bạn sẽ muốn hoặc muốn sử dụng khóa thay thế thay vì để lộ khóa chính.

Vì vậy, nếu sự hiểu biết của tôi về thiết kế theo hướng tên miền là chính xác, các khóa chính không cần và do đó không nên bị lộ, và câu đố tốt. Chúng xấu xí và tù túng phong cách của tôi. Nhưng nếu chúng ta chọn không bao gồm các khóa chính trong mô hình miền, sẽ có hậu quả:

1. Rõ ràng, các đối tượng truyền dữ liệu (DTO) xuất phát từ các tổ hợp mô hình miền sẽ không có khóa chính
2. Sắp tới DTO sẽ không có khóa chính

Vì vậy, có an toàn không khi nói rằng nếu bạn thực sự giữ nguyên trạng thái và loại bỏ các khóa chính trong mô hình miền của mình, bạn nên chuẩn bị để có thể xử lý mọi yêu cầu theo các chỉ số duy nhất trên khóa chính đó?

Nói cách khác, giải pháp nào sau đây là cách tiếp cận chính xác để xử lý việc xác định các đối tượng cụ thể sau khi loại bỏ PK trong các mô hình miền?

1. Có thể xác định các đối tượng bạn cần xử lý bằng các thuộc tính khác
2. Lấy khóa chính trở lại trong DTO; tức là loại bỏ PK khi ánh xạ từ kiên trì sang miền, sau đó kết hợp lại PK khi ánh xạ từ miền sang DTO?

EDIT: Hãy làm cho bê tông này.

Giả sử mô hình tên miền của tôi là VoIPProviderbao gồm các trường như Name, Description, URL, cũng như tài liệu tham khảo thích ProviderType, PhysicalAddressvà Transactions.

Bây giờ hãy nói rằng tôi muốn xây dựng một dịch vụ web cho phép người dùng đặc quyền quản lý VoIPProviders.

Có lẽ một ID thân thiện với người dùng là vô dụng trong trường hợp này; xét cho cùng, các nhà cung cấp VoIP là các công ty có tên có xu hướng khác biệt theo nghĩa máy tính và thậm chí đủ khác biệt theo nghĩa con người vì lý do kinh doanh. Vì vậy, có thể đủ để nói rằng một duy nhất VoIPProviderhoàn toàn được xác định bởi (Name, URL). Vì vậy, bây giờ hãy nói rằng tôi cần một phương pháp PUT api/providers/voipđể người dùng đặc quyền có thể cập nhật VoIPnhà cung cấp. Họ gửi lên một VoIPProviderDTO, bao gồm nhiều nhưng không phải tất cả các lĩnh vực từ VoIPProvider, bao gồm cả một số khả năng làm phẳng. Tuy nhiên, tôi không thể đọc được suy nghĩ của họ và họ vẫn cần cho tôi biết chúng tôi đang nói về nhà cung cấp nào.

Có vẻ như tôi có 2 (có thể 3) tùy chọn:

1. Bao gồm khóa chính hoặc khóa thay thế trong mô hình miền của tôi và gửi nó đến DTO và ngược lại
2. Xác định nhà cung cấp mà chúng tôi quan tâm thông qua chỉ mục duy nhất, như (Name, Url)
3. Giới thiệu một số loại đối tượng trung gian luôn có thể ánh xạ giữa lớp, miền và DTO theo cách không phơi bày chi tiết triển khai về lớp lưu giữ - nói bằng cách giới thiệu một định danh tạm thời trong bộ nhớ khi đi từ miền sang DTO và ngược lại,

Đây là cách chúng tôi giải quyết vấn đề này (từ hơn 15 năm trước, khi mà ngay cả thuật ngữ "thiết kế hướng tên miền" cũng không được phát minh):

• khi ánh xạ mô hình miền sang triển khai cơ sở dữ liệu hoặc mô hình lớp bằng ngôn ngữ lập trình cụ thể, bạn có một quy tắc nhất quán, đơn giản như "đối với mỗi đối tượng miền được ánh xạ tới bảng quan hệ, khóa chính là" TablenameID ".
• khóa chính này hoàn toàn nhân tạo, nó luôn có cùng loại và không có ý nghĩa kinh doanh - chỉ là khóa thay thế
• "phiên bản đồ họa" của mô hình miền của bạn (phiên bản bạn sử dụng để nói chuyện với các chuyên gia tên miền) không chứa các khóa chính. Bạn không tiếp xúc chúng trực tiếp với các chuyên gia (nhưng bạn tiếp xúc chúng với bất kỳ ai thực sự triển khai mã cho hệ thống).

Vì vậy, bất cứ khi nào bạn cần một khóa chính cho các mục đích kỹ thuật (như ánh xạ quan hệ vào cơ sở dữ liệu), bạn có sẵn một khóa, nhưng miễn là bạn không muốn "nhìn thấy nó", hãy thay đổi mức độ trừu tượng của bạn thành "mô hình chuyên gia tên miền ". Và bạn không phải duy trì "hai mô hình" (một mô hình có PK và một mô hình không có); thay vào đó, chỉ duy trì một mô hình không có PK và sử dụng trình tạo mã để tạo DDL cho DB của bạn, tự động thêm PK theo quy tắc ánh xạ.

Lưu ý rằng điều này không cấm thêm bất kỳ "khóa doanh nghiệp" nào như "Số thứ tự" bổ sung, bên cạnh việc thay thế OrderID. Về mặt kỹ thuật, các khóa nghiệp vụ này trở thành khóa thay thế khi ánh xạ vào cơ sở dữ liệu của bạn. Chỉ cần tránh sử dụng những thứ này để tạo tham chiếu đến các bảng khác, luôn thích sử dụng các khóa thay thế nếu có thể, điều này sẽ khiến mọi thứ dễ dàng hơn rất nhiều.

Đối với nhận xét của bạn: sử dụng khóa thay thế để xác định hồ sơ là không có hoạt động liên quan đến kinh doanh, đó là một hoạt động kỹ thuật hoàn toàn. Để làm rõ điều này, hãy xem ví dụ của bạn: miễn là bạn không xác định các ràng buộc độc đáo bổ sung, có thể có hai đối tượng VoIPProvider có cùng kết hợp (tên, url), nhưng các VoIPProviderID khác nhau.

Bạn cần có khả năng xác định nhiều đối tượng bằng một số chỉ mục duy nhất và không phải là khóa chính là gì (hoặc ít nhất là ngụ ý một đối tượng có mặt).

Các chỉ mục duy nhất có sẵn để bạn có thể hạn chế thêm lược đồ DB của mình, không phải là một thay thế bán buôn cho PK. Nếu bạn không phơi bày PK vì chúng xấu, nhưng thay vào đó là lộ một khóa duy nhất ... bạn thực sự không làm gì khác. (Tôi cho rằng bạn không nhận được PK và cột nhận dạng trộn lẫn ở đây?)

Không có khóa chính trong frontend, không có cách nào dễ dàng để phụ trợ biết bạn đang gửi gì. Để khắc phục rằng bạn sẽ cần rất nhiều công việc phân tích dữ liệu, điều này sẽ làm giảm hiệu suất và có thể mất nhiều thời gian hơn và xấu hơn so với việc gắn một khóa cho mỗi mục.

Ví dụ: giả sử tôi muốn chỉnh sửa tin nhắn trong ứng dụng; Làm thế nào để ứng dụng biết thông báo nào tôi muốn chỉnh sửa mà không có khóa chính được đính kèm? Chỉnh sửa các đối tượng xảy ra mọi lúc và làm điều đó mà không có phím là không thể. Nhưng nếu bạn có các đối tượng không cần chỉnh sửa thì hãy bỏ qua khóa nếu bạn nghĩ rằng nó gây mất tập trung, nhưng có các khóa chính có thể cải thiện hiệu suất ở đây.

Lý do chúng tôi sử dụng PK không liên quan đến kinh doanh là để đảm bảo rằng hệ thống của chúng tôi có một phương pháp dễ dàng và nhất quán để xác định những gì người dùng muốn.

Tôi thấy bạn đã trả lời với một bình luận: MessageSender, MessageRecipient, TimeSent (cho một tin nhắn). Bạn có thể VẪN có sự mơ hồ theo cách này (ví dụ, với các thông báo được tạo bởi hệ thống kích hoạt trên một cái gì đó xảy ra thường xuyên). Và làm thế nào bạn sẽ xác nhận MessageSender và MessageRecipient ở đây? Giả sử bạn xác thực chúng bằng FirstName, Lastname, DateOfBirth, cuối cùng bạn sẽ gặp phải tình huống bạn có 2 người sinh ra trong cùng một ngày với cùng một tên. Chưa kể rằng bạn sẽ gặp phải một tình huống mà bạn có một tin nhắn được đặt tên tacostacostacos-America-1980-Doc Brown-France-1965-23/5/2014-11:43:54.003UTC+200. Đó là một con quái vật của một cái tên, và bạn vẫn không có gì đảm bảo bạn sẽ chỉ có 1 trong số đó.

Lý do chúng tôi sử dụng khóa chính là vì chúng tôi BIẾT nó sẽ là duy nhất trong suốt vòng đời của phần mềm, bất kể dữ liệu nào được nhập và chúng tôi BIẾT nó sẽ là định dạng có thể dự đoán được (điều gì xảy ra nếu khóa trên của bạn có dấu gạch ngang trong một tên người dùng? toàn bộ hệ thống của bạn đi shit).

Bạn không cần phải hiển thị ID của mình cho người dùng của bạn. Bạn có thể ẩn điều đó (trong tầm nhìn rõ ràng nếu cần thiết, thông qua URL).

Một lý do khác khiến PK rất hữu ích là một thứ bạn có thể suy ra từ trên: PK làm cho nó để bạn không phải buộc máy tính diễn giải mã do người dùng tạo. Nếu người dùng Trung Quốc sử dụng mã của bạn và nhập vào một loạt các ký tự tiếng Trung, mã của bạn đột nhiên không cần phải làm việc với các mã này trong nội bộ, nhưng đơn giản là có thể sử dụng Hướng dẫn mà hệ thống tạo ra. Nếu bạn có một người dùng tiếng Ả Rập nhập văn bản tiếng Ả Rập, hệ thống của bạn không phải đối phó với nội bộ đó, nhưng về cơ bản có thể bỏ qua rằng họ đang ở đó.

Như những người khác đã nói, Guid là thứ có thể được lưu trữ bên trong với kích thước cố định. Bạn biết những gì bạn làm việc với và đó là một cái gì đó có thể được sử dụng phổ biến. Bạn không cần tạo quy tắc thiết kế về cách bạn tạo một số nhận dạng nhất định và lưu nó. Nếu hệ thống của bạn chỉ nhận 10 chữ cái đầu tiên của tên, thì nó không thấy bất kỳ sự khác biệt nào giữa Michael Guggenheimer và Michael Gugstein, và nó sẽ gây nhầm lẫn cho 2. Nếu bạn cắt nó ở bất kỳ độ dài tùy ý nào, bạn có thể gặp nhầm lẫn. Nếu bạn giới hạn đầu vào của người dùng, bạn có thể gặp phải các vấn đề với giới hạn người dùng.

Khi tôi xem xét các hệ thống hiện có như Dynamics CRM, họ cũng sử dụng khóa bên trong (PK) cho người dùng để gọi một bản ghi. Nếu người dùng có một truy vấn không liên quan đến ID, họ sẽ trả về một loạt các câu trả lời có thể và cho phép người dùng chọn từ đó. Nếu có bất kỳ cơ hội mơ hồ nào, họ sẽ đưa ra lựa chọn cho người dùng.

Cuối cùng, nó cũng có sự bảo mật thông qua che khuất. Nếu bạn không biết ID hồ sơ, lựa chọn duy nhất của bạn là đoán nó. nếu ID dễ đoán (vì thông tin được tạo ra công khai), bất kỳ ai cũng có thể thay đổi. Bạn thậm chí có thể khiến người dùng thay đổi nó thông qua các phương thức CSRF hoặc XSS cổ điển. Bây giờ, rõ ràng bảo mật của bạn đã được xử lý và giảm thiểu trước khi xuất bản phiên bản trực tiếp, nhưng bạn vẫn nên làm cho việc lạm dụng tiềm năng khó xảy ra hơn.

Khi cấp mã định danh cho hệ thống bên ngoài, bạn chỉ nên cung cấp URI hoặc thay thế một khóa hoặc một bộ khóa có cùng thuộc tính với URI, thay vì trực tiếp hiển thị khóa chính của cơ sở dữ liệu (từ đây trở đi cả URI hoặc khóa hoặc một tập hợp các khóa có cùng thuộc tính với URI giống như URI, nói cách khác, URI dưới đây không nhất thiết có nghĩa là RFC 3986 URI).

Một URI có thể có hoặc không chứa khóa chính của đối tượng và nó thực sự có thể hoặc không bao gồm các khóa thay thế. Nó không thực sự quan trọng. Vấn đề là chỉ có hệ thống tạo URI mới được phép phân tách hoặc kết hợp URI để hình thành sự hiểu biết về đối tượng được đề cập là gì. Các hệ thống bên ngoài phải luôn sử dụng URI làm định danh mờ. Sẽ không có vấn đề gì nếu người dùng con người có thể xác định rằng một phần của URI thực sự là khóa thay thế cơ sở dữ liệu hoặc nó bao gồm một số khóa nghiệp vụ được gộp lại với nhau hoặc đó thực sự là một cơ sở của 64 giá trị đó. Những điều này không liên quan. Vấn đề là hệ thống bên ngoài không cần phải được yêu cầu để hiểu định nghĩa có nghĩa là gì để sử dụng định danh. Không bao giờ cần phải có hệ thống bên ngoài để phân tích các thành phần trong mã định danh hoặc kết hợp một mã định danh với các mã định danh khác để chỉ một cái gì đó trong hệ thống của bạn.

Việc sử dụng GUID đáp ứng một số tiêu chí này, tuy nhiên, số nhận dạng như GUID có thể khó quay trở lại đối tượng ngay cả trong hệ thống của bạn, do đó, các khóa mờ đối với ngay cả hệ thống của bạn như GUID chỉ nên được sử dụng nếu máy khách phân tích URI / định danh thực sự đặt ra một rủi ro bảo mật.

Quay lại ví dụ VoIP của bạn, giả sử rằng nhà cung cấp VoIP có thể được xác định duy nhất bằng (VoIPProviderID) hoặc bởi (Tên, URL) hoặc bởi (GUID). Khi một bên ngoài nhu cầu hệ thống để cập nhật các nhà cung cấp VoIP, nó chỉ có thể vượt qua một PUT / nhà cung cấp / by-id / 1234 hay PUT /provider/foo-voip/bar-domain.comhay PUT /3F2504E0-4F89-41D3-9A0C-0305E82C3301và hệ thống của bạn sẽ hiểu rằng các hệ thống bên ngoài muốn cập nhật VoIPProvider. Các URI này được tạo bởi hệ thống của bạn và chỉ hệ thống của bạn cần hiểu rằng tất cả chúng đều có nghĩa giống nhau. Hệ thống bên ngoài chỉ nên coi bất cứ thứ gì trong URI là cơ bản a PUT <whatever>.

Giả sử rằng bạn có dữ liệu cho các nhà cung cấp VoIP khác nhau được lưu trữ trong các bảng khác nhau với các lược đồ khác nhau (do đó, bộ khóa hoàn toàn khác nhau xác định mỗi nhà cung cấp VoIP dựa trên bảng mà họ được lưu trữ). Khi bạn có URI, chúng có thể được truy cập thống nhất bởi hệ thống bên ngoài, mà không liên quan đến cách hệ thống của bạn xác định nhà cung cấp VoIP cụ thể. Đối với hệ thống bên ngoài, tất cả chỉ là con trỏ mờ.

Khi hệ thống của bạn sử dụng URI để chỉ các đối tượng theo cách như vậy, bạn sẽ không rò rỉ bất cứ điều gì liên quan đến cách bạn triển khai hệ thống của mình. Bạn tạo URI và khách hàng chỉ cần chuyển lại cho bạn.

Tôi sẽ phải nhắm mục tiêu tuyên bố ngây thơ và không chính xác này:

Có lẽ một ID thân thiện với người dùng là vô dụng trong trường hợp này; xét cho cùng, các nhà cung cấp VoIP là các công ty có tên có xu hướng khác biệt theo nghĩa máy tính và thậm chí đủ khác biệt theo nghĩa con người vì lý do kinh doanh.

Tên là khủng khiếp như chìa khóa, vì chúng thường xuyên thay đổi. Một công ty có thể có nhiều tên trong suốt cuộc đời của mình, công ty có thể hợp nhất, tách ra, sáp nhập lại, tạo ra một công ty con riêng biệt cho các mục đích thuế cụ thể có 0 nhân viên nhưng tất cả các khách hàng sau đó thuê nhân viên từ một công ty con hoàn toàn khác.

Sau đó, chúng ta đi vào thực tế rằng tên công ty thậm chí không phải là duy nhất từ ​​xa, như được thể hiện bởi mốc Apple so với Apple .

Một đối tượng tốt mapper quan hệ hoặc khuôn khổ nên họ trừu tượng các phím chính đi và làm cho những vô hình, nhưng ở đó, và họ thường sẽ là chỉ cách để nhận diện một đối tượng trong cơ sở dữ liệu của bạn.

Để tham khảo, tôi thích cách django xử lý việc này:

class VoipProvider(models.Model):
    name=fields.TextField()
    address=fields.TextField()

class Customer(models.Model):
    name=fields.TextField()
    address=fields.TextField()
    voipProvider=fields.ForeignKeyField(VoipProvider)

Theo cách này, các chi tiết của nhà cung cấp của khách hàng có thể được truy cập bằng mã bằng cách sử dụng:

myCustomer.voipProvider.name #returns the name of the customers VOIP Provider.

Mặc dù các khóa Chính / Ngoại không hiển thị, nhưng chúng ở đó và có thể được sử dụng để truy cập các mục, nhưng bị trừu tượng hóa.

Tôi nghĩ rằng chúng ta vẫn thường nhìn không chính xác vấn đề này từ góc độ của DB: oh, không có khóa tự nhiên, vì vậy chúng ta cần tạo một khóa thay thế. Ồ không, chúng tôi không thể đưa khóa thay thế trở lại vào các đối tượng miền, điều đó bị rò rỉ, v.v.

Tuy nhiên, đôi khi một thái độ tốt hơn là: nếu một đối tượng (miền) doanh nghiệp không có khóa tự nhiên, thì có lẽ nó nên được cung cấp. Đây là một vấn đề miền kinh doanh hai lần: Thứ nhất, mọi thứ cần một bản sắc, ngay cả khi không có cơ sở dữ liệu. Thứ hai, mặc dù chúng tôi cố gắng giả vờ kiên trì là một số ý tưởng trừu tượng vô hình đối với miền, nhưng thực tế là sự kiên trì vẫn là một khái niệm kinh doanh. Rõ ràng, có một số vấn đề trong đó khóa tự nhiên được chọn không được DB hỗ trợ làm khóa chính (ví dụ: GUID trên một số hệ thống) - trong trường hợp này, bạn sẽ cần thêm khóa thay thế.

Do đó, bạn kết thúc ở một nơi rất giống nhau, ví dụ: khách hàng của bạn có ID số nguyên, nhưng thay vì cảm thấy bị bệnh vì đã bị rò rỉ từ DB sang tên miền, bạn cảm thấy hạnh phúc vì doanh nghiệp đã đồng ý rằng tất cả khách hàng sẽ được chỉ định ID và bạn đang duy trì điều đó với DB, như bạn phải. Bạn vẫn được tự do giới thiệu người thay thế, ví dụ: để hỗ trợ đổi tên ID khách hàng.

Cách tiếp cận này cũng có nghĩa là nếu một đối tượng miền chạm vào lớp lưu giữ và không có ID, thì đó có thể là một loại đối tượng giá trị, vì vậy không cần ID.