Kiến trúc một ứng dụng dịch vụ mô-đun


11

Tôi đang xem xét kiến ​​trúc một giải pháp mới có tính mô đun rất tự nhiên và muốn tạo ra một cấu trúc hỗ trợ thiết kế đó để cho phép mở rộng dễ dàng trong tương lai, phân tách rõ ràng các mối quan tâm, cấp phép theo mô-đun, v.v. tìm thấy trên web về các ứng dụng mô-đun hoặc hỗn hợp là trung tâm UI, tập trung vào Silverlight, WPF, v.v. Trong trường hợp của tôi, tôi đang phát triển một ứng dụng dịch vụ WCF sẽ được sử dụng bởi các nhà phát triển khác làm việc trên các dự án UI khác nhau.

Lý lịch

Mục tiêu của dự án của tôi là tạo ra một nguồn logic kinh doanh / miền tập trung để hỗ trợ một số ứng dụng kinh doanh hiện đang trùng lặp quy trình, quy tắc, v.v. Và trong khi không phải mọi lợi ích của mô đun hóa sẽ đạt được, tôi muốn nắm bắt cơ hội để thiết lập một khuôn khổ sẽ tận dụng những phần mà chúng ta có thể tận dụng.

Tôi đã bắt đầu thiết kế bằng cách xem API được ứng dụng dịch vụ trưng ra. Rõ ràng là các dịch vụ có thể được tách riêng dọc theo các dòng mô-đun mà tôi đang xem xét. Chẳng hạn, tôi sẽ có các dịch vụ FinanceService, InventoryService, PersonnelService, v.v., nhóm các hoạt động dịch vụ của tôi để cung cấp sự gắn kết cao trong API trong khi giữ cho khớp nối ở mức thấp để khách hàng chỉ phải sử dụng các dịch vụ phù hợp với ứng dụng của họ.

Điều đó có ý nghĩa với tôi rằng sau đó tôi có thể có các mô-đun riêng cho từng dịch vụ này, chẳng hạn như MyApp.Finance, MyApp.Inventory, My.Personnel, v.v. Mối quan tâm xuyên suốt và các loại chia sẻ sẽ có trong hội đồng chia sẻ MyApp. Từ đây tôi có một chút trói lại.

(Ồ, tôi nên đề cập rằng tôi sẽ sử dụng bộ chứa IoC cho Dependency Injection để giữ cho ứng dụng được kết nối lỏng lẻo. Tôi sẽ đề cập đến cái nào vì tôi không muốn mở hộp Pandora!)

Trong MyApp.Servicehost, tôi sẽ tạo một tệp máy chủ dịch vụ (.svc) tương ứng với từng mô-đun, FinanceService.svc chẳng hạn. Máy chủ dịch vụ cần tên của dịch vụ tương ứng với thông tin trong tệp cấu hình có chứa giao diện xác định hợp đồng dịch vụ. Cấu hình IoC sau đó được sử dụng để ánh xạ triển khai cụ thể giao diện sẽ sử dụng.

1. Lớp dịch vụ có nên triển khai API và ủy quyền cho các mô-đun hay các mô-đun nên được khép kín (trong đó chúng chứa mọi thứ liên quan đến mô-đun đó, bao gồm cả việc triển khai dịch vụ)?

Một cách để tiếp cận vấn đề là có một "mô-đun" MyApp.Service chứa việc thực hiện các hợp đồng dịch vụ. Mỗi lớp dịch vụ chỉ cần ủy quyền cho một lớp khác mô đun thích hợp int eh có chứa logic miền cho hoạt động. Ví dụ: lớp WCF của FinanceService trong MyApp.Service ủy nhiệm cho một giao diện khác được triển khai trong mô-đun Tài chính để thực hiện thao tác. Điều này sẽ cho phép tôi duy trì mặt tiền dịch vụ mỏng và 'trình cắm' triển khai thực hiện dịch vụ và loại bỏ sự cần thiết của các mô-đun để lo lắng về WCF, ví dụ.

Mặt khác, có lẽ nên để mỗi mô-đun độc lập ở chỗ nó có giao diện và cách triển khai. Máy chủ dịch vụ đề cập đến giao diện hợp đồng dịch vụ được tìm thấy trong mô-đun và IoC được cấu hình để sử dụng triển khai phù hợp từ mô-đun. Điều này có nghĩa là việc thêm một mô-đun mới có thể được thực hiện mà không có thay đổi nào đối với lớp dịch vụ ngoài việc thêm tệp .svc mới và thông tin cấu hình IoC.

Tôi đang suy nghĩ về tác động nếu tôi chuyển từ WCF tiêu chuẩn sang giao diện dịch vụ RESTful hoặc có thể chuyển sang các dịch vụ RIA hoặc một cái gì đó. Nếu mỗi mô-đun chứa việc thực hiện hợp đồng dịch vụ, thì tôi phải thay đổi mọi mô-đun nếu tôi thay đổi công nghệ dịch vụ hoặc cách tiếp cận. Nhưng, nếu mặt tiền là mô-đun riêng của nó, thì tôi chỉ phải trao đổi phần đó để thực hiện thay đổi. Các mô-đun sau đó sẽ phải thực hiện một tập hợp hợp đồng (giao diện) khác nhau, có thể được xác định trong hội đồng chia sẻ ???

2. Cách tốt nhất để xử lý chia sẻ tài nguyên giữa các mô-đun và / hoặc phụ thuộc giữa các mô-đun là gì?

Lấy ví dụ, một hoạt động nhận. Đầu tiên, điều này có nghĩa là điều này đi vào mô-đun Hàng tồn kho vì nhận hàng là một chức năng kiểm kê. Tuy nhiên, cũng có một khía cạnh tài chính ở chỗ chúng tôi cần tạo Biên lai và ủy quyền thanh toán.

Một mặt, tôi sẽ sử dụng một số loại sự kiện / nhắn tin tên miền để giao tiếp hoạt động. Mô-đun Hàng tồn kho tăng một Hàng hóa Nhận đượcEvent được xử lý bởi mô-đun Tài chính để tạo Biên nhận và bắt đầu quy trình thanh toán. Tuy nhiên, điều này có nghĩa là mô-đun Tài chính cần biết về các mặt hàng tồn kho đã nhận được. Tôi chỉ có thể tham khảo chúng bằng ID nhưng nếu tôi cần thêm thông tin cho Biên nhận, chẳng hạn như tên và / hoặc mô tả, chi phí đơn vị, v.v. thì sao? Liệu có ý nghĩa cho mỗi mô-đun có phiên bản riêng của một mặt hàng tồn kho được thiết kế để phù hợp với nhu cầu của mô-đun đó không? Trong trường hợp đó, mô-đun Tài chính sẽ phải thực hiện tra cứu riêng các mặt hàng tồn kho khi xử lý Hàng hóaReceuredEvent.

...

Tôi đã sử dụng ví dụ này một cách có chủ đích vì tôi đã làm việc rất nhiều với các hệ thống ERP khác nhau và biết rằng chúng được thiết kế với kiểu mô đun này - tôi chỉ không biết làm thế nào. Tôi cũng không đề cập rõ ràng về nó ở trên, nhưng tôi thích tuân theo các hiệu trưởng của Thiết kế hướng miền trong việc kiến ​​trúc giải pháp và tin rằng loại mô đun này phù hợp với khu vực đó.

Bất kỳ trợ giúp nhận được đầu của tôi xung quanh này được đánh giá rất cao.


1
Lấy làm tiếc. Không thể tìm thấy một câu hỏi trong tất cả các suy nghĩ. Câu hỏi là gì?
S.Lott

1
Hãy tìm những dấu hỏi. Có một số điểm tôi đưa ra các tùy chọn nhưng không giả định một giải pháp và một số câu hỏi cụ thể để giúp hướng dẫn quy trình đi đúng hướng.
SonOfPirate

1
@SonOfPirate: Xin lỗi. Tôi đã hy vọng bạn có thể dành thời gian để làm nổi bật hoặc nhấn mạnh các câu hỏi để những người khác có thể giúp bạn.
S.Lott

4
Tôi đồng ý với S.Lott. Tôi xin lỗi, nhưng đây không phải là một câu hỏi, đó là một dòng ý thức. Chúng tôi có thể giúp bạn tốt hơn rất nhiều nếu bạn tập trung vào một hoặc hai câu hỏi tập trung và cố gắng tách các mối quan tâm về kiến ​​trúc khỏi các chi tiết triển khai.
Aaronaught

1
@SonOfPirate: "Architecture" là về cấu trúc và truyền đạt cấu trúc đó đến các nhà phát triển khác. Nó bắt đầu với mô tả. Nó phải đạt được mức độ rõ ràng và minh bạch cho phép các nhà phát triển khác hoàn toàn "hiểu" và tuân theo các nguyên tắc thiết kế kiến ​​trúc trong mọi việc họ làm.
S.Lott

Câu trả lời:


2

Liệu có ý nghĩa cho mỗi mô-đun có phiên bản riêng của một mặt hàng tồn kho được thiết kế để phù hợp với nhu cầu của mô-đun đó không? Trong trường hợp đó, mô-đun Tài chính sẽ phải thực hiện tra cứu riêng các mặt hàng tồn kho khi xử lý Hàng hóaReceuredEvent. Tôi vẽ ranh giới giữa mô đun và nhu cầu chia sẻ thông tin ở đâu?

Bạn sẽ luôn phải chấp nhận đánh đổi. Đó là tất cả để nói với câu hỏi của bạn thực sự. Đó là một thực tiễn tốt để giữ các thực thể trong một hội đồng riêng biệt, vì vậy nhiều ứng dụng giữ chúng trong một thư viện chia sẻ. Nhưng điều đó có nghĩa là không có ràng buộc logic kinh doanh (vật lý). Thực hiện tra cứu của riêng bạn có nghĩa là rất nhiều mã dự phòng mà tôi chỉ thực hiện nếu bạn có các yêu cầu đặc biệt trong cả hai mô-đun. Tất nhiên, nhìn từ góc độ kiến ​​trúc, Mô-đun tài chính và Mô-đun hàng tồn kho của bạn dù sao cũng phải chia sẻ một sự phụ thuộc. Mô-đun tài chính rất có thể phụ thuộc vào Mô-đun hàng tồn kho. Nếu các yêu cầu cho phép bạn để một mô-đun phụ thuộc vào một mô-đun khác, thì tôi sẽ nói rằng bạn có thể gói gọn các thực thể trong các mô-đun mà chúng thuộc về nhiều nhất. Bạn' sẽ cần tìm một sự cân bằng tốt giữa sự khác biệt về thể chất (phụ thuộc chung) và bảo trì. Quá nhiều phụ thuộc được chia sẻ có thể gây ra cơn ác mộng bảo trì các phiên bản. Ngoài ra, với ORM, sẽ có rắc rối nếu bạn muốn ánh xạ các quan hệ mới tới các thực thể hiện có hoặc mở rộng chúng từ các mô-đun phụ thuộc vào mô-đun chứa thực thể.

Nếu bạn không sử dụng ORM thì hãy nhớ rằng tất cả các mô-đun của bạn có thể chia sẻ cùng một cơ sở dữ liệu, như thường lệ. Bạn có thể sử dụng nó như một mặt bằng chung.

Bạn cũng có thể giữ dữ liệu đơn giản (về CSV / kết quả, ví dụ) và sử dụng dịch vụ nhắn tin trung tâm để thông báo cho các mô-đun đã đăng ký với dữ liệu mới cùng với một số thông tin meta. Điều đó có nghĩa là không có sự phụ thuộc thực sự, nhưng hy sinh loại an toàn và hợp đồng và có thể có rắc rối với dữ liệu không đúng định dạng. Tôi đoán đó là có bao nhiêu hệ thống ERP lớn làm điều đó.

Vì vậy, trong ngắn hạn, bạn sẽ phải quyết định loại giao diện bạn muốn. Nhiều mô đun hơn dẫn đến ít hợp đồng hơn và ngược lại.

Có thể sử dụng một thư viện dùng chung cho các đối tượng dữ liệu của tôi và dịch vụ nhắn tin trung tâm với mẫu phân nhóm xuất bản, đó có vẻ là giải pháp tốt nhất đối với tôi.


Cũng đồng ý với điều này - nhắn tin + pub / sub và thư viện chia sẻ cho các hợp đồng dto (repo nuget nội bộ). Tôi đã tự hỏi những câu hỏi tương tự như @SonOfPirate cho đến khi bài viết này đặt nó trong bối cảnh cho tôi: msdn.microsoft.com/en-us/l
Library / bb245678.aspx
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.