Làm thế nào để xác định rõ ràng ranh giới của một bối cảnh bị ràng buộc

Sau khoảng một tháng đọc và nghiên cứu DDD, tôi quyết định bắt đầu dự án của riêng mình và tạo DDD với những bối cảnh bị ràng buộc>

• Khách hàng
• Các sản phẩm
• Đơn đặt hàng
• Thanh toán

Mỗi bối cảnh giới hạn có API còn lại là lớp trình bày, lớp miền, lớp liên tục.

Cho đến nay rất tốt, mã đang chạy trơn tru, nhưng đến từ một thế giới nguyên khối, tôi vẫn đang cố gắng tìm ra những điều sau đây:

• khi tôi muốn tạo một khách hàng mới, phát hành hóa đơn mới, tạo đơn hàng mới tôi muốn ví dụ như danh sách các quốc gia truy cập. Tôi có

a) tạo danh sách các quốc gia ở mỗi BC

b) tạo Quốc gia BC -> API và sử dụng API để nhận danh sách các quốc gia có sẵn

c) sử dụng API của bên thứ 3 và kéo dữ liệu qua lớp chống ăn mòn ở mỗi BC

• khi tích hợp với API của bên thứ 3 bằng cách sử dụng lớp chống ăn mòn hoặc lớp bộ điều hợp, dữ liệu nào phải được đưa vào mô hình miền của tôi? Ví dụ: nếu tôi muốn tích hợp API zendesk với Client BC. Tôi có cần chỉ một TicketID trong miền của mình không, hoặc tôi phải trích xuất tất cả dữ liệu từ Zendesk mà tôi muốn truy cập và sử dụng trong Client BC?

Nếu ứng dụng MVC của tôi thực sự nhận được dữ liệu từ các API (các lớp trình bày trong bối cảnh bị ràng buộc của tôi), tôi thấy rất khó xác định rõ ràng ranh giới của từng BC. Điều đó có nghĩa là một BC được thiết kế đúng sẽ phục vụ một bộ điều khiển MVC duy nhất mà không cần phải sử dụng các API bổ sung?

Nếu các bối cảnh giới hạn khác nhau của bạn hiểu ý nghĩa / mục đích của một quốc gia khác nhau, thì bạn cần mô hình hóa nó phù hợp khác nhau ở mỗi quốc gia. Tuy nhiên, nếu chúng ta chỉ nói đơn giản về dữ liệu tham chiếu của mã và tên ISO, thì tôi tin rằng nó khá công bằng và chuẩn để cất nó ở bất cứ đâu thuận tiện và có thể truy cập được cho tất cả các bên quan tâm. Ví dụ: cơ sở dữ liệu, tệp cấu hình, dịch vụ web, v.v.

Tôi cũng muốn nhìn vào mô hình của bạn một chút. Các phần bạn đã liệt kê rất có thể là "thực thể" trong một "bối cảnh giới hạn", tùy thuộc vào cấu trúc của công ty. BC thường kết thúc được xác định xung quanh các khu vực / phòng ban / nhóm khác nhau, vì đó thường là ranh giới tự nhiên giữa "ngôn ngữ phổ biến". Vì vậy, ví dụ, thay vì Bán hàng / Sản phẩm / Đơn hàng, tôi mong muốn các BC sẽ đồng hành cùng các hoạt động Bán hàng / Sản xuất / Nhập kho.

Bên trong những BC đó, bạn không tập trung vào các danh từ. Bạn tập trung vào các trường hợp sử dụng và tạo các mô hình của danh từ có thể đáp ứng các trường hợp sử dụng. Các phương thức trên "tổng hợp gốc" thực thi các trường hợp sử dụng và thực hiện các thay đổi phù hợp cho các mô hình liên quan.

... Tất cả các mô hình đều sai, nhưng một số là hữu ích.

Cũng nên nhớ rằng mỗi BC có thể sử dụng một hệ thống hoặc kiến ​​trúc hoàn toàn khác nhau. Một BC nhất định có thể không đáng sử dụng "các thành phần phần mềm DDD", và hầu hết trong số chúng có thể không. DDD ít nói về các thành phần phần mềm được quy định và nhiều hơn về quá trình thiết kế phần mềm. Vấn đề là tập trung vào việc tìm hiểu bối cảnh giới hạn của công ty, vạch ra các ngôn ngữ phổ biến của từng bối cảnh và mô hình hóa mã cho bối cảnh đó bằng ngôn ngữ phổ biến của họ. Theo cách đó khi bạn tương tác với những người nắm giữ cổ phần và tham khảo mã, có vẻ như họ đang nói theo thuật ngữ kinh doanh mà họ hiểu. Và nhận ra rằng cùng một từ có ý nghĩa khác nhau trong các BC khác nhau.

Có các mẫu cụ thể được đưa ra bởi DDD (ví dụ: kho lưu trữ, phân lớp cụ thể, v.v.) có nghĩa là kết thúc. Nhưng những mẫu này không được đảm bảo là mẫu tốt nhất cho mọi trường hợp, ngay cả trong DDD. Giống như DDD không phải là "câu trả lời" cho mọi dự án. Bạn chỉ cần làm những gì phân tích của bạn cho thấy là điều thiết thực nhất để làm.

Từ câu hỏi của bạn, tôi nghĩ rằng bạn hiểu nhầm bối cảnh bị ràng buộc. Bạn có thể muốn đọc lại Chương 14 của cuốn sách màu xanh .

Cố gắng trả lời chung chung - bạn phải cẩn thận về việc chia sẻ các khái niệm giữa hai bối cảnh bị ràng buộc khác nhau. Rốt cuộc, một phần lý do mà ranh giới tồn tại là ngôn ngữ có mặt khắp nơi thay đổi. Giả sử rằng cùng một dữ liệu (và cùng một đại diện) của một thực thể có thể được sử dụng trong cả hai bối cảnh là ngây thơ - nó có thể đúng, có thể sai, nhưng không có cách nào tốt cho những người trong chúng ta ở bên ngoài, mà không cần truy cập để các chuyên gia tên miền của bạn, để đánh giá.

Ví dụ: trong miền khách hàng, "quốc gia" có thể liên quan đến cư trú hoặc quyền công dân. Trong thanh toán, nó có thể liên quan đến tỷ giá hối đoái. Trong một số tên miền đó, bạn có thể cần phải lo lắng về thuế quan và những thứ tương tự.

Một câu hỏi thứ hai mà bạn cần nêu ra là mô hình nào trong số các mô hình của bạn là sổ ghi chép cho dữ liệu "được chia sẻ". Trong trường hợp của "đất nước", câu trả lời đúng có lẽ là không ai trong số họ! Cấu trúc liên kết địa chính trị không được kiểm soát bởi mô hình của bạn.

Điều gì sẽ xảy ra trong các mô hình miền của bạn khi một quốc gia bị chiếm đóng bởi một thế lực nước ngoài?

Ghi nhớ; rất nhiều người trong chúng ta đã quen nghĩ về cấu trúc dữ liệu; mối quan hệ giữa một phần dữ liệu và một phần khác là gì. Và thật tuyệt vời khi bạn đang xem xét các báo cáo và cố gắng đảm bảo rằng tất cả dữ liệu bạn cần đã được thu thập bởi giải pháp của bạn. Nhưng các mô hình miền không chỉ là về cấu trúc, mà còn về sự thay đổi. Bạn cũng cần phải chú ý đến phần đó và đảm bảo rằng bạn hiểu rõ cách thức dữ liệu hạn chế các thay đổi (và cách các ràng buộc đó thay đổi từ bối cảnh bị ràng buộc sang bối cảnh tiếp theo).

Các khái niệm bạn đề cập (Khách hàng, Sản phẩm, Đơn hàng, Thanh toán) thường được trình bày trong một Mô hình Miền duy nhất và do đó Bối cảnh bị ràng buộc. Tôi đề nghị bạn hiểu những khái niệm này không chính xác.

Tôi coi chủ đề này là xác định bối cảnh bị ràng buộc bằng cách sử dụng ánh xạ khả năng kinh doanh hoặc các kỹ thuật tương tự khác như phân tích chuỗi giá trị. Nó đi xuống theo các bước sau:

1. Xác định trách nhiệm cấp cao hơn hoặc khả năng kinh doanh của hệ thống của bạn. Cách tốt nhất để làm điều đó tôi nghĩ là gợi lên các bước mà doanh nghiệp của bạn trải qua để có được giá trị kinh doanh. Các ranh giới logic mà bạn đưa ra là các dịch vụ kinh doanh của bạn, hoặc, nếu bạn thích, các bối cảnh bị ràng buộc.
2. Tìm hiểu sâu hơn trong từng dịch vụ.
3. Xác định thông tin liên lạc giữa các dịch vụ của bạn cùng với hai điểm đầu tiên.

Vì vậy, trọng tâm ban đầu là làm thế nào kinh doanh của bạn hoạt động.

Vài lời khuyên thực tế:

1. Nếu một trong những bối cảnh / dịch vụ / vv của bạn cần một số dữ liệu bối cảnh khác, rất có thể ranh giới của bạn là sai.
2. Cách truyền thông bối cảnh rất mong muốn là dựa trên sự kiện. Đây là một chìa khóa cho khả năng mở rộng và độ tin cậy. Nếu bạn cần giao tiếp đồng bộ, rất có thể, không phải ranh giới của bạn là sai, một lần nữa. Bên cạnh đó, giao tiếp đồng bộ sẽ giết chết hệ thống của bạn.
3. Tên miền của bạn cuối cùng phù hợp hơn bạn nghĩ. Giống như mọi người khác. Đừng cố làm mọi thứ nhất quán 100%. Không có ý nghĩa thực tế trong đó.
4. Các bối cảnh không cần phải được sắp xếp. Họ khép kín. Như con người.

Với phương pháp này, bạn kết thúc với các dịch vụ tự chủ cao, có thể bảo trì và đáng tin cậy. Bạn có thể muốn kiểm tra một ví dụ về xác định ranh giới ngữ cảnh.