DDD Bounded Bối cảnh & Tên miền?

Tôi đã làm việc trong một ứng dụng tương đối phức tạp với 10 bảng cơ sở dữ liệu (Tập hợp, Thực thể / Đối tượng Giá trị) và áp dụng DDD. Tại thời điểm này, về cơ bản, DDD-Lite có nghĩa là có Ứng dụng / Dịch vụ miền, Mô hình miền (Thực thể, Đối tượng giá trị) và Kho lưu trữ.

Tôi đã chọn một cuốn sách Thực hiện DDD và điều đầu tiên anh ấy nhắc đến là DDD-Lite và Bối cảnh và các sự kiện miền bị thiếu là những lỗi đầu tiên thường thấy khi bắt đầu DDD.

Hiện tại tôi đã thử tổ chức Mô hình miền theo các mối quan hệ Tổng hợp và sử dụng các không gian tên để thể hiện nó.

Tôi không thấy lợi ích / nhược điểm liên quan đến việc tách dự án Mô hình miền thành các bối cảnh giới hạn riêng biệt (chưa). Có lẽ nó sẽ trở nên rõ ràng sau này nhưng tôi muốn một số phản hồi thực tế về Bối cảnh bị ràng buộc (và có thể cả các tên miền phụ, v.v. nếu chúng liên kết với nó).

Hãy xem xét một công ty có một vài bộ phận khác nhau:

• Phát triển phần mềm
• Nhân sự
• Kế toán

Bạn có thể đưa ra một mô hình người dùng có thể đại diện rõ ràng cho tất cả các lĩnh vực kinh doanh đó không? Hãy nghĩ về thực thể Người dùng có thể trông như thế nào trong mỗi người. Có lẽ nó được chia thành ba thực thể khác nhau:

• Nhà phát triển
• Nhân viên
• Người được trả tiền

Nỗ lực để khởi tạo một người dùng trong mỗi bối cảnh là khác nhau đáng kể. Có lẽ nó giống như thế này:

• Nhân viên mới (ssn, tên, tham gia, hẹn hò, giới tính)
• Nhà phát triển mới (Nhân viên, máy trạm, thông tin đăng nhập)
• Người nhận thanh toán mới (Nhân viên, vai trò)

xin lỗi, thật khó để minh họa chính xác nếu không có mô hình miền thích hợp để tham khảo

Nếu bạn đã sử dụng một triển khai ngây thơ và sử dụng một thực thể người dùng duy nhất, thì đó sẽ là một mô hình dữ liệu thiếu máu chứa đầy các getters và setters, bởi vì bạn không thể đại diện đầy đủ cho người dùng ở mọi nơi.

Có những ranh giới rõ ràng trong kinh doanh, vì vậy thật hữu ích khi mô hình hóa chúng theo cách đó. Người dùng đăng nhập so với người dùng trong hệ thống bảng lương so với người dùng chơi trò chơi đều rất khác nhau, ngay cả khi họ là một phần của cùng một hệ thống lớn.

Suy nghĩ theo một cách khác - bây giờ bạn có thể tạo mã quản lý nhà phát triển của mình thật nhẹ và độc lập với phần còn lại của hệ thống. Nó có thể sử dụng các loại chính xác hơn với ít hành lý để lo lắng. Đây là bước để xây dựng các hệ thống con nhỏ hơn mà cuối cùng có thể được trích xuất ra khỏi ứng dụng của chính nó.

Tôi có thể cho bạn một ví dụ khác. Hãy xem xét bạn có một số hệ thống thương mại điện tử. Bạn sẽ có sản phẩm ở đó, tuy nhiên sản phẩm sẽ là một phần của ít nhất hai miền khác nhau:

• Danh mục sản phẩm, nơi bạn giữ mô tả sản phẩm của mình và tất cả các thuộc tính
• Hàng tồn kho, nơi bạn có mức tồn kho sản phẩm

Nếu bạn có một bối cảnh giới hạn cho cả hai miền, giải pháp của bạn có thể nhanh chóng trở thành một quả bóng lớn bởi vì bạn sẽ bắt đầu tham khảo chéo nó. Cuối cùng, bạn sẽ không có hai tên miền nữa. Hàng tồn kho sản phẩm của bạn sẽ được tha hồ tham khảo danh mục sản phẩm và ngược lại. Vì kết quả của việc này, bạn sẽ không thể thay đổi một tên miền mà không chạm vào tên miền khác ngay cả khi bạn hoàn toàn nhận ra điều này là không bắt buộc. Các mô hình của bạn trở nên phụ thuộc lẫn nhau và liên kết chặt chẽ, và phụ thuộc theo chiều hướng xấu - bị phụ thuộc vào việc thực hiện.

Tuy nhiên, nếu bạn có hai bối cảnh bị ràng buộc, tất cả các thay đổi bạn thực hiện trong một tên miền sẽ không ảnh hưởng đến vùng kia ngay khi bạn giữ cho các kênh liên lạc của mình rõ ràng. Điều đó có nghĩa là bạn cần phải sao chép dữ liệu nhưng đây là chi phí ít nhất để trả cho ứng dụng dựa trên thành phần được ghép nối một cách mất mát. Các miền của bạn có thể nói chuyện với nhau bằng các sự kiện tên miền. Ngay cả khi bạn không có kế hoạch để có ứng dụng dựa trên SOA ngay từ đầu, bạn sẽ có thể mở rộng đến mức đó khi bạn cần với nỗ lực tương đối thấp vì bạn chỉ thay đổi vận chuyển cho các sự kiện trong miền của mình, giữ nguyên ý tưởng phía sau.

Cập nhật: Có một kỹ năng tốt trên SkillMatter, từ Eric Evans. Ông đưa ra một sự tương tự của câu chuyện cũ, khi một số người mù mô tả một con voi từ quan điểm của họ. Vì mỗi người chỉ có thể chạm vào một phần của con voi, nên họ mô tả nó như một "cái cây", "bức tường", "con rắn", "sợi dây". Và mỗi người trong số họ là đúng trong bối cảnh của họ. Bối cảnh bị ràng buộc là nơi ngôn ngữ phổ biến sống. Bên ngoài bối cảnh, các thuật ngữ này có thể có ý nghĩa hoàn toàn khác nhau nhưng bên trong bối cảnh, ngôn ngữ giống nhau trên nhiều lĩnh vực. Greg Young mạnh mẽ đề nghị bắt đầu đọc cuốn sách màu xanh từ chương 11, vì các khái niệm cơ bản, quan trọng nhất được giải thích ở đó. Việc tập trung vào các mẫu chiến thuật ở phần đầu của cuốn sách khiến cho cách tiếp cận "ánh sáng DDD" này trở nên rất phổ biến,