Làm cách nào để thể hiện bối cảnh bị chặn?

Question

Ý tôi là - về thể chất, trong mã. Tổ chức đặt tên, không gian tên, thư mục, hội đồng, cơ sở dữ liệu/s.

Các bối cảnh bị chặn phải tương tác như thế nào?

Ví dụ: vui lòng sử dụng cổ điển e-commerce business domain.

Answer 1

Tôi muốn nói 'nó phụ thuộc'

Một số lần nó có thể là đủ để lập bản đồ các đơn vị BC của bạn vào cơ sở dữ liệu giống nhau và đôi khi bạn có thể có cơ sở dữ liệu khác nhau cho BC của bạn.

IMO, thương mại điện tử có thể lớn hơn BC so với tên miền hoàn chỉnh.

Tôi đã dành một chút quá nhiều thời gian tại một đại lý bán hàng toàn bộ nơi họ bán sản phẩm thực phẩm.

Vì vậy, tên miền là "toàn bộ bán hàng" và bối cảnh bị chặn là, hàng tồn kho, mua, bán hàng, hóa đơn, danh mục sản phẩm và thương mại điện tử (có lẽ tôi sử dụng từ ngữ tiếng anh sai ở đây)

Mỗi BC biết về "sản phẩm" nhưng tất cả đều có quan điểm khác nhau về sản phẩm.

ví dụ: Mua hàng có thể có một thực thể sản phẩm với thông tin nhà cung cấp, giá mua, vv gắn liền với nó.

Trong khi một sản phẩm trong lĩnh vực thương mại điện tử sẽ được mô hình từ một điểm của khách hàng, nó sẽ có thông tin liên quan cho khách hàng rằng xem video đó, mức giá cụ thể của họ, vv

thương mại điện tử BC sẽ lấy thông tin sản phẩm từ nhiều nguồn; danh mục sản phẩm và bán hàng. nơi thông tin cơ bản là từ danh mục sản phẩm và giá cụ thể của khách hàng là từ bán hàng.

Vì vậy, kho lưu trữ sản phẩm trong thương mại điện tử BC có thể thực hiện ánh xạ ngữ cảnh từ các BC khác (thông qua dịch vụ của một số loại, rất có thể là web hoặc wcf trong trường hợp của tôi) để xây dựng thực thể sản phẩm thương mại điện tử của chúng tôi)

Cá nhân tôi làm mô hình này như các hội đồng riêng biệt, tôi sẽ có một mô hình thương mại điện tử và một mô hình bán hàng.

Hầu hết thông tin trong mô hình thương mại điện tử của tôi sẽ đến từ các nguồn bên ngoài và sẽ không được lưu giữ cục bộ. Chỉ những thứ như giỏ mua hàng sẽ được lưu giữ cục bộ liên tục vì các đối tượng đó thuộc sở hữu của mô hình thương mại điện tử.

Khi khách hàng cố gắng hoàn tất giao dịch mua của họ, tôi sẽ tạo một đơn đặt hàng trước từ giỏ hàng và sau đó chuyển nó cho BC bán hàng. Hoặc bằng cuộc gọi dịch vụ trực tiếp hoặc qua hàng đợi tin nhắn.

Vì vậy, trong ngắn hạn, tôi có xu hướng xây dựng các hệ thống của mình xung quanh một BC cụ thể và chỉ tương tác với các dịch vụ khác của BC qua các dịch vụ.

Tôi biết rằng rất nhiều người đã đặt BC của họ trong cùng một hội đồng và sử dụng nhiều BC từ cùng một ứng dụng, v.v. Nhưng tôi chỉ thấy nó kỳ quặc tại sao một ứng dụng cho một mục đích cụ thể nên biết về nhiều bối cảnh. Tôi muốn làm cho nó biết về chỉ có một bối cảnh và sau đó vượt qua bất cứ dữ liệu nào tôi cần cho các ứng dụng khác.

Answer 2

Tôi chắc chắn đồng ý rằng tất cả đều phụ thuộc, nhưng có một số nguyên tắc có thể/nên được tuân theo.Mục đích của bối cảnh giới hạn là, tốt, ranh giới. Ranh giới tách biệt trên một phần của ứng dụng từ một khác bằng cách giới thiệu một hợp đồng được xác định rõ ràng (giao diện).

Tôi có xu hướng đối xử với BC như Dịch vụ trong SOA. Đối với tôi, điều đó có nghĩa lý tưởng là chúng là các ứng dụng riêng biệt (các tiến trình OS/các trang IIS). Binaries cũng được tách ra tất nhiên. Tất cả các thông tin liên lạc giữa BCs là lý tưởng không đồng bộ. Trong thế giới thực nó khó có thể, nhưng ít nhất tôi không cho phép giao dịch chéo-BC cho họ là tà ác thuần túy.

Hy vọng điều đó sẽ hữu ích.