Triển khai DDD: người dùng và quyền

Tôi đang làm việc trên một ứng dụng nhỏ đang cố gắng nắm bắt các nguyên tắc của thiết kế hướng tên miền. Nếu thành công, đây có thể là một thí điểm cho một dự án lớn hơn. Tôi đang cố gắng theo dõi cuốn sách "Thực hiện thiết kế hướng tên miền" (của Vaughn Vernon) và cố gắng thực hiện một diễn đàn thảo luận đơn giản, tương tự. Tôi cũng đã kiểm tra các mẫu IDDD trên github. Tôi có một số khó khăn khi áp dụng Danh tính và Quyền truy cập vào trường hợp của tôi. Hãy để tôi cung cấp một số thông tin cơ bản:

• Tôi (hy vọng) hiểu lý do đằng sau tách biệt người dùng và logic quyền: đó là một miền hỗ trợ và đó là một bối cảnh bị ràng buộc khác.
• Trong miền lõi, không có người dùng, chỉ có Tác giả, Người điều hành, v.v. Những thứ này được tạo bằng cách tiếp cận với bối cảnh Nhận dạng và Truy cập bằng cách sử dụng một dịch vụ và sau đó dịch các đối tượng Người dùng đã nhận sang và Người điều hành.

• Các hoạt động tên miền được gọi với vai trò liên quan là một tham số: vd:

  ModeratePost( ..., moderator);

• Phương thức của đối tượng miền kiểm tra xem đối tượng Moderator đã cho không phải là null (đối tượng Moderator sẽ là null nếu người dùng được hỏi từ bối cảnh Nhận dạng và Truy cập không có vai trò Moderator).

• Trong một trường hợp, nó thực hiện kiểm tra bổ sung trước khi thay đổi Bài đăng:

  if (forum.IsModeratedby(moderator))

Câu hỏi của tôi là:

• Trong trường hợp sau, không phải mối quan tâm bảo mật đã hòa trộn trở lại vào miền lõi? Trước đây các cuốn sách nói "với những người có thể đăng một chủ đề, hoặc trong những điều kiện được phép. Một diễn đàn chỉ cần biết rằng một Tác giả đang làm điều đó ngay bây giờ".

• Việc triển khai dựa trên vai trò trong cuốn sách khá đơn giản: khi Moderator là miền cốt lõi cố gắng chuyển đổi userId hiện tại thành phiên bản Moderator hoặc thành Tác giả khi cần. Dịch vụ sẽ phản hồi với trường hợp thích hợp hoặc null nếu người dùng không có vai trò bắt buộc. Tuy nhiên, tôi không thể thấy làm thế nào tôi có thể thích ứng điều này với một mô hình bảo mật phức tạp hơn; dự án hiện tại của chúng tôi, tôi đang thử nghiệm có một mô hình khá phức tạp với các nhóm, ACL, v.v.

Ngay cả với các quy tắc không phức tạp lắm, như: "Bài viết chỉ nên được chỉnh sửa bởi Chủ sở hữu hoặc Biên tập viên", cách tiếp cận này dường như bị phá vỡ, hoặc ít nhất là tôi không thấy cách chính xác để thực hiện nó.

Bằng cách hỏi bối cảnh Nhận dạng và Truy cập cho một cá thể Chủ sở hữu, không cảm thấy đúng và tôi sẽ kết thúc với ngày càng nhiều lớp liên quan đến bảo mật trong miền lõi. Ngoài ra, tôi sẽ cần chuyển không chỉ userId, mà cả định danh của tài nguyên được bảo vệ (id của bài đăng, diễn đàn, v.v.) cho bối cảnh bảo mật, có lẽ không nên quan tâm đến những điều này (có đúng không? )

Bằng cách kéo các quyền vào miền lõi và kiểm tra chúng trong các phương thức của các đối tượng miền hoặc trong các dịch vụ, tôi sẽ kết thúc ở ô vuông thứ nhất: trộn các mối quan tâm bảo mật với tên miền.

Tôi đã đọc ở đâu đó (và tôi có xu hướng đồng ý với nó) rằng những thứ liên quan đến quyền này không nên là một phần của miền lõi, trừ khi bảo mật và quyền là chính miền chính. Liệu một quy tắc đơn giản như quy tắc nêu trên có thể biện minh cho việc bảo mật là một phần của miền lõi không?

Đôi khi rất khó để phân biệt giữa các quy tắc kiểm soát truy cập thực và các bất biến miền biên giới trong kiểm soát truy cập.

Đặc biệt, các quy tắc phụ thuộc vào dữ liệu chỉ có sẵn trong quá trình của một phần logic miền cụ thể có thể không dễ dàng rút ra khỏi miền. Thông thường, Kiểm soát truy cập được gọi trước hoặc sau khi thao tác miền được thực hiện nhưng không trong thời gian.

assert (forum.IsModeratedBy(moderator))Ví dụ của Vaughn Vernon có lẽ đã ở ngoài Miền, nhưng không phải lúc nào cũng khả thi.

Tôi sẽ cần chuyển không chỉ userId, mà cả định danh của tài nguyên được bảo vệ (id của bài đăng, diễn đàn, v.v.) vào bối cảnh bảo mật, có lẽ không nên quan tâm đến những điều này (có đúng không?)

Nếu có BC bảo mật và bạn muốn nó xử lý logic đó, thì không cần biết Diễn đàn chi tiết là gì nhưng:

• Nó chỉ có thể có kiến ​​thức về các khái niệm như "được kiểm duyệt bởi" và cấp hoặc từ chối quyền truy cập tương ứng.
• Bạn có thể có logic bộ điều hợp đăng ký các sự kiện Tên miền cốt lõi và chuyển chúng sang các cặp giá trị khóa đơn giản (tài nguyên, người dùng được ủy quyền) để Security BC lưu trữ và sử dụng.

Xác thực và Ủy quyền là một ví dụ tồi cho DDD.

Cả hai điều này đều không phải là một phần của Miền trừ khi công ty của bạn tạo ra các sản phẩm bảo mật.

Yêu cầu doanh nghiệp hoặc tên miền là, hoặc nên là "Tôi yêu cầu xác thực dựa trên vai trò"

Sau đó, bạn kiểm tra vai trò trước khi gọi một chức năng miền.

Trường hợp bạn có các yêu cầu phức tạp như 'Tôi có thể chỉnh sửa các bài đăng của riêng mình nhưng không phải là người khác' đảm bảo rằng tên miền của bạn tách chức năng chỉnh sửa ra EditOwnPost()và EditOthersPost()để bạn có một chức năng đơn giản để ánh xạ vai trò

Bạn cũng có thể tách chức năng thành Đối tượng miền, chẳng hạn như Poster.EditPost()và Moderator.EditPost()đây là cách tiếp cận OOP hơn, mặc dù lựa chọn của bạn có thể phụ thuộc vào việc phương thức của bạn nằm trong Dịch vụ miền hay Đối tượng miền.

Tuy nhiên, bạn chọn tách mã, ánh xạ vai trò sẽ xảy ra bên ngoài Miền. vì vậy, ví dụ nếu bạn có bộ điều khiển webapi:

PostController : ApiController
{
    [Authorize(Roles = "User")]
    public void EditOwnPost(string postId, string newContent)
    {
        this.postDomainService.EditOwnPost(postId, string newContent);
    }

    [Authorize(Roles = "Moderator")]
    public void EditOtherPost(string postId, string newContent)
    {
        this.postDomainService.EditOtherPost(postId, string newContent);
    }
}

Như bạn có thể thấy mặc dù ánh xạ vai trò được thực hiện trên lớp lưu trữ, logic phức tạp của những gì cấu thành chỉnh sửa bài đăng của riêng bạn hoặc của người khác là một phần của miền.

Tên miền nhận ra sự khác biệt của các hành động, nhưng yêu cầu bảo mật chỉ đơn giản là "chức năng có thể bị giới hạn bởi vai trò" .

Điều này có lẽ rõ ràng hơn với sự phân tách các đối tượng miền, nhưng về cơ bản, bạn đang kiểm tra phương thức xây dựng đối tượng thay vì phương thức gọi phương thức dịch vụ. Yêu cầu của bạn, nếu bạn vẫn muốn nói nó như một phần của miền sẽ trở thành 'chỉ người điều hành mới có thể xây dựng đối tượng người điều hành'