Tên miền phụ, thực sự là gì?

Trong nghiên cứu thiết kế hướng tên miền (DDD), tôi đã bắt gặp khái niệm tên miền phụ, nhưng tôi nghĩ tôi chưa hiểu được. Hiểu biết đầu tiên của tôi về điều này là một tên miền phụ là một tập hợp con của miền của ứng dụng. Nói cách khác, đó là một phân vùng của không gian vấn đề. Tôi đã đọc được rằng có ba loại tên miền phụ:

• tên miền phụ
• tên miền phụ hỗ trợ
• tên miền phụ chung.

Sự hiểu biết của tôi có phần giống như thế này: Chúng tôi chọn tên miền của ứng dụng và nó khá phức tạp. Sau đó, chúng tôi xem xét nó và chúng tôi tìm ra cách phân chia nó thành các phần đơn giản hơn, một số trong đó sẽ là tên miền phụ cốt lõi và một số trong đó sẽ hỗ trợ, trong khi những cái khác sẽ chung chung.

Khi tìm kiếm thêm thông tin, tôi đã tìm thấy một số người nói điều gì đó khác biệt: Đó chỉ là một tên miền phụ tồn tại, cùng với một số tên miền phụ chung và không có tên miền phụ hỗ trợ nào.

Vì vậy, câu hỏi của tôi là:

1. Tên miền phụ, thực sự là gì? Là sự hiểu biết đầu tiên của tôi là chính xác, hay đó là điều thứ hai tôi đọc?
2. Làm thế nào là ý tưởng về tên miền phụ hữu ích?
3. Một số tiêu chí tốt để xác định tên miền phụ là gì? Chúng ta nên nghĩ gì khi quyết định tên miền phụ để sử dụng tốt hơn ý tưởng này?

EDIT: Tìm kiếm thêm một chút, tôi tìm thấy như sau:

Hãy nghĩ về một hệ thống thương mại điện tử. Ban đầu bạn có thể nói rằng đó là một ứng dụng của bối cảnh mua sắm. Nếu bạn nhìn kỹ hơn, bạn sẽ thấy có những bối cảnh khác nữa, chẳng hạn như Hàng tồn kho, Giao hàng, Tài khoản, v.v.

Đây là những gì ban đầu tôi nghĩ rằng một tên miền phụ là. Chúng tôi chọn một tên miền (tên miền mua sắm) và chia nó thành các tên miền phụ đơn giản hơn (hàng tồn kho, giao hàng, tài khoản, v.v.). Nhưng trong văn bản trong câu hỏi, họ đề cập đến những điều này như bối cảnh. Vì vậy, sự hiểu biết trước đây của tôi không phải là tên miền phụ mà là bối cảnh?

Tôi đã tìm thấy một câu hỏi ở đây trên trang web này về sự khác biệt giữa tên miền phụ và bối cảnh bị ràng buộc. Câu trả lời nói rằng các tên miền phụ là một phân vùng của không gian vấn đề, trong khi các bối cảnh là các phân vùng của không gian giải pháp. Tuy nhiên, tách bối cảnh mua sắm thành hàng tồn kho, giao hàng, tài khoản, v.v., không phải là một phân vùng khái niệm. Đó là, có phải trong không gian vấn đề chứ không phải là không gian giải pháp?

Tuyên bố miễn trừ trách nhiệm : Tôi không phải là chuyên gia DDD, nhưng tôi sẽ cố hết sức ở đây để trả lời câu hỏi của bạn.

Hãy sử dụng Nhà bán lẻ sách trực tuyến làm ví dụ. Một người bán sách đang đề nghị bán sách trên trang web của mình, nhưng anh ta không tự in sách. Thay vào đó, anh ta có một danh sách dài các "Nhà cung cấp sách", những người in và chuyển sách đến kho của anh ta, anh ta đã đóng gói chúng và gửi chúng cho khách hàng trên toàn thế giới.

Bạn có thể tưởng tượng các đội làm việc trong công ty đó?

1. Nhóm liệt kê : Nhóm chọn sách nào họ nên liệt kê trên Trang web, tùy thuộc vào kho của nhà cung cấp.
2. Nhóm thực hiện : chịu trách nhiệm thu thập các đơn đặt hàng từ Trang web và quản lý vòng đời của đơn hàng.
3. Nhóm thương mại : đây là những người xử lý việc thêm hoặc xóa nhà cung cấp khỏi hệ thống.
4. Nhóm tiếp thị : chịu trách nhiệm cho các chiến dịch và cung cấp.
5. Nhóm kho : chịu trách nhiệm thu thập sách từ các nhà cung cấp và vận chuyển chúng.

Mỗi đội sẽ sử dụng các thuật ngữ riêng để mô tả những gì nó đang làm. Các đội sẽ sử dụng ngôn ngữ tên miền hoặc "Ngôn ngữ phổ biến", như Eric Evans gọi nó. Thông thường, mỗi đội sẽ có một mô hình tinh thần khác nhau về thực thể là gì. Ví dụ:

Listing team: BOOK(book_id, ISBN, title, price, weight, length, width )  
Fulfillment team: BOOK(book_id, totalPrice, sold_quantity)   
Shipping team: ITEM(book_id, delivery_date) --> they refer to the book entity as "item" 

Tên miền phụ là một phần cụ thể của tên miền, trong đó một số người dùng sử dụng Ngôn ngữ Ubiquitous nhất định. Khi ngôn ngữ thay đổi, đây là dấu hiệu cho thấy bạn đang chuyển sang tên miền phụ khác.

Nếu hai đội sử dụng các thuật ngữ giống nhau thì sao? Cả đội hoàn thành và niêm yết đều gọi cuốn sách là "cuốn sách". Bạn sẽ phải hỏi họ, "cuốn sách dành cho bạn là gì? Thuộc tính chính của nó là gì? Nó được sử dụng như thế nào?"

Câu trả lời cho những câu hỏi này sẽ dẫn đến hai mô hình miền khác nhau hoặc tương tự nhau. Sự khác biệt giữa hai mô hình càng lớn, càng cho thấy đây là hai bối cảnh / miền phụ khác nhau. Điều ngược lại cũng đúng. Hai mô hình càng giống nhau thì càng có nhiều khả năng chúng là một phần của cùng một tên miền phụ.

Điều này có thể dẫn đến kết quả rất thú vị trong mô hình của bạn. Bạn có thể phát hiện ra rằng bên trong tên miền phụ hoàn thành, các đơn đặt hàng đi qua các trạng thái khác nhau (mới -> được yêu cầu -> được vận chuyển). Có thể mỗi trạng thái này yêu cầu quản lý phức tạp và các thuộc tính khác nhau, vì vậy bạn có thể chia tên miền phụ này thành một số tên miền phụ khác.

Điều này đưa ra một câu hỏi về kích thước của (các) tên miền phụ nên là gì. Câu trả lời là "hãy để mô hình miền quyết định điều đó". Bất cứ khi nào bạn thấy một sự thay đổi trong UL và mô hình, sau đó vẽ một ranh giới cho tên miền phụ đó.

Hãy nhớ rằng DDD là tất cả về doanh nghiệp, con người và (các) giao tiếp giữa họ. Hãy để điều đó mô hình của bạn.