Mô hình miền dùng chung giữa các dịch vụ siêu nhỏ khác nhau

Hãy tưởng tượng một kịch bản của hai dịch vụ siêu nhỏ khác nhau. Một để xử lý Xác thực trong dịch vụ, một cái khác đảm nhiệm Quản lý người dùng. Cả hai đều có khái niệm về Người dùng và sẽ nói về Người dùng thông qua các cuộc gọi với nhau.

Mô hình miền của "Người dùng" sẽ thuộc về đâu? Cả hai sẽ có một đại diện khác nhau về những gì Người dùng ở cấp độ của cơ sở dữ liệu? Thế còn khi chúng ta có UserDTO được sử dụng trong các lệnh gọi API, cả hai sẽ có một API cho API tương ứng của họ không?

Giải pháp chung được chấp nhận cho loại vấn đề kiến ​​trúc này là gì?

Trong một kiến ​​trúc microservice, mỗi cái hoàn toàn độc lập với những cái khác và nó phải ẩn các chi tiết của việc thực hiện bên trong.

Nếu bạn chia sẻ mô hình, bạn sẽ ghép các dịch vụ siêu nhỏ và mất một trong những lợi thế lớn nhất mà mỗi nhóm có thể phát triển dịch vụ siêu nhỏ của mình mà không bị hạn chế và cần biết cách phát triển các dịch vụ siêu nhỏ khác. Hãy nhớ rằng bạn thậm chí có thể sử dụng các ngôn ngữ khác nhau trong mỗi ngôn ngữ, điều này sẽ khó khăn nếu bạn bắt đầu kết hợp microservice.

Nếu họ quá liên quan có lẽ họ thực sự là một người như @soru nói.

Câu hỏi liên quan:

• Tại sao việc đọc dữ liệu từ cơ sở dữ liệu lại được sở hữu bởi một dịch vụ siêu nhỏ khác
• Làm thế nào để bạn xử lý các khái niệm được chia sẻ trong một kiến ​​trúc microservice?

Nếu hai dịch vụ được đan xen đầy đủ rằng sẽ rất khó để thực hiện chúng mà không chia sẻ DTO và các đối tượng mô hình khác, đó là một dấu hiệu mạnh mẽ mà bạn không nên có hai dịch vụ.

Chắc chắn ví dụ này có rất ít ý nghĩa như hai dịch vụ; thật khó để tưởng tượng một đặc tả cho 'Quản lý người dùng' phức tạp đến mức nó sẽ khiến cả một nhóm bận rộn đến mức họ không có thời gian để xác thực.

Nếu vì một lý do nào đó, họ sẽ giao tiếp bằng cách sử dụng các chuỗi cơ bản tùy ý, như trong OAuth 2.0 .

Bạn có thể nghĩ về chúng như hai bối cảnh giới hạn riêng biệt (theo cách nói của Thiết kế hướng tên miền). Họ không nên chia sẻ bất kỳ dữ liệu nào giữa chúng, ngoài ID được sử dụng để tương quan "Người dùng" của bối cảnh Xác thực với "Người dùng" của bối cảnh khác. Mỗi người có thể có đại diện riêng của họ về "Người dùng" là gì và mô hình miền của riêng họ, chỉ là thông tin cần thiết để thực hiện trách nhiệm kinh doanh của họ.

Hãy nhớ rằng một mô hình miền không cố gắng mô hình hóa một "điều" trong thế giới thực, nhưng điều đó là gì trong một bối cảnh cụ thể (chẳng hạn như Quản lý nhận dạng / ủy quyền hoặc Nhân sự, v.v.).

Cả hai đều có khái niệm về Người dùng và sẽ nói về Người dùng thông qua các cuộc gọi với nhau.

Tôi cũng đồng ý với những gì @soru nói. Nếu một dịch vụ cần dữ liệu của dịch vụ khác, thì ranh giới của chúng là sai.

Một giải pháp tốt là những gì @pnschofield đã đưa ra - coi dịch vụ của bạn là bối cảnh bị ràng buộc.

Nói về chủ đề này, hãy nói ngắn gọn: các mô hình miền chia sẻ giết chết quyền tự chủ dịch vụ, biến hệ thống microservice của bạn thành nguyên khối phân tán. Mà rõ ràng là còn tồi tệ hơn một tảng đá nguyên khối.

Vì vậy, vẫn còn một câu hỏi chung chưa được giải quyết - làm thế nào để xác định ranh giới dịch vụ hoặc bối cảnh, để chúng phát triển mạnh về độ kết dính cao và độ tốt khớp nối lỏng lẻo.

Tôi đã đưa ra một giải pháp để coi bối cảnh của mình là khả năng kinh doanh. Đó là một trách nhiệm kinh doanh cấp cao hơn, chức năng kinh doanh, đóng góp cho mục tiêu kinh doanh tổng thể. Bạn có thể nghĩ về chúng như các bước mà tổ chức của bạn cần phải đi bộ mặc dù để có được giá trị kinh doanh.

Trình tự điển hình của tôi về các bước tôi thực hiện khi xác định ranh giới dịch vụ là như sau:

1. Xác định khả năng kinh doanh cấp cao hơn. Thông thường họ giống nhau giữa các tổ chức từ cùng một tên miền. Bạn có thể cảm nhận được nó trông như thế nào khi kiểm tra mô hình chuỗi giá trị của Porter .
2. Trong mỗi khả năng, đào sâu hơn và xác định các khả năng phụ.
3. Lưu ý giao tiếp giữa các khả năng. Nhìn vào những gì một tổ chức làm. Thông thường, giao tiếp được tập trung trong các khả năng, thông báo phần còn lại về kết quả công việc của nó. Vì vậy, khi thực hiện kiến ​​trúc kỹ thuật, dịch vụ của bạn cũng nên liên lạc qua các sự kiện. Điều này có nhiều hậu quả tích cực. Với phương pháp này, các dịch vụ của bạn được tự chủ và gắn kết. Họ không cần giao tiếp đồng bộ và giao dịch phân tán.

Có lẽ một ví dụ về kỹ thuật này sẽ được bạn quan tâm. Đừng ngần ngại cho tôi biết bạn nghĩ gì, vì tôi thấy phương pháp này thực sự có lợi. Chắc chắn nó có thể làm việc cho bạn là tốt.

Microservice không phải là về "chia sẻ không có gì", mà là "chia sẻ càng ít càng tốt". Trong hầu hết các trường hợp, "Người dùng" là thực thể phổ biến (chỉ vì Người dùng được xác định bởi một số định danh được chia sẻ - userId / email / phone). Loại thực thể như vậy được chia sẻ theo định nghĩa. Mô hình người dùng nằm ngoài phạm vi một microservice. Vì vậy, bạn phải có một số lược đồ toàn cầu, nơi Người dùng (chỉ các trường phổ biến nhất của họ) nên được đặt. Trong trường hợp nghiêm ngặt là id chỉ.