Cấu trúc mã để xử lý nhiều thị trường? (quy tắc kinh doanh khác nhau cho mọi tiểu bang ở Hoa Kỳ)

Chúng tôi đang phát triển một ứng dụng có các yêu cầu hơi khác nhau cho từng thị trường kinh doanh (quốc gia và tiểu bang) mà nó có sẵn. Có vẻ như là một tình huống phổ biến nhưng tôi dường như không thể tìm thấy một bài viết hay về cấu trúc mã / mô-đun cho kịch bản này.
Đó là một ứng dụng C # và chúng tôi đang tranh luận giữa các mẫu Chiến lược và Mẫu nhưng cũng có sự xem xét về cấu trúc thư mục và quy ước đặt tên. Có vẻ như một dự án riêng cho mỗi tiểu bang sẽ nhanh chóng không thể quản lý được (ví dụ: 5 dịch vụ cốt lõi X 50 dự án tùy chỉnh trạng thái) = 250 dự án !!) Có lẽ 1 dự án tùy chỉnh cho mỗi chuyên ngành xử lý dịch vụ được tổ chức trong các thư mục con cho mỗi tiểu bang?

Có một ứng dụng duy nhất và thiết kế giải pháp cấu hình phù hợp.

JacquesB gợi ý về điều này, nhưng tôi muốn nói rõ hơn. Bạn phải làm điều này bằng cách cấu hình thay vì phát triển hơn 50 phiên bản của cơ sở mã. Bất cứ điều gì khác sẽ được điên cuồng không thể quản lý.

Nếu có các yêu cầu phức tạp không thể xử lý bằng các tham số cấu hình đơn giản, hãy thiết kế một giải pháp cấu hình phức tạp hơn.

Cấu hình của bạn thậm chí có thể có một ngôn ngữ kịch bản đơn giản xác định các yêu cầu logic. Được thôi. Điều quan trọng là "cấu hình" phải được tách biệt rõ ràng khỏi cơ sở mã của ứng dụng.

Nếu không, những thứ như xác định và sửa lỗi sẽ là một mớ hỗn độn. Với phiên bản thông thường ngoài các phiên bản dành riêng cho miền địa phương, bạn sẽ có hàng trăm phiên bản trong lĩnh vực này. Và bạn sẽ không thể dễ dàng biết được lỗi có liên quan đến mã cụ thể của miền địa phương hay mã cơ sở hay không.

Bắt đầu suy nghĩ về các trường hợp cạnh bây giờ.

Đây là một tình huống có nguy cơ cao đưa ra các giả định xấu sẽ vô cùng tốn kém. Chẳng hạn như "Mỗi người dùng ứng dụng sẽ chỉ cần hoạt động trong một miền." Điều đó có đúng không? Hãy chắc chắn rằng bạn suy nghĩ thực sự khó khăn về các vấn đề như vậy càng sớm càng tốt.

Nó thực sự phụ thuộc vào những gì khác nhau. Đây có phải là thứ có thể được biểu thị hoàn toàn bằng cấu hình (ví dụ: thuế suất) hoặc bạn có thực sự cần logic mã riêng cho từng trạng thái không? Bạn càng có thể xử lý hoàn toàn bằng cấu hình thì càng tốt!

Bạn rất có thể không cần mã riêng biệt theo tiểu bang. Ví dụ, bạn đề cập rằng một số thị trường phát hành hoàn tiền trong khi các vấn đề khác thay thế. Đây vẫn chỉ là hai đường dẫn mã bạn cần kiểm tra. Sau đó, bạn có thể có một cấu hình cho biết đường dẫn nào sẽ được sử dụng cho trạng thái nào. Điều này tốt hơn nhiều khi có mã riêng cho từng tiểu bang. Bạn vẫn chỉ cần kiểm tra hai mã đường dẫn rater hơn 50.

Nếu bạn cảm thấy cần phải viết mã riêng cho mỗi 50 tiểu bang, có lẽ bạn đang làm sai. Bạn chắc chắn không nên có các dự án riêng biệt cho mỗi tiểu bang hoặc thậm chí có "50 khác nhau" bất cứ thứ gì ngoại trừ các phần cấu hình.

Tôi đã có một số kinh nghiệm thực tế với các dự án như vậy, và ít nhất có thể đưa ra một số hướng dẫn chung.

• JacquesB hoàn toàn đúng khi cấu hình là người bạn tốt nhất của bạn. Cho dù bạn đặt cấu hình đó trong các tệp hoặc trong các bảng cơ sở dữ liệu là một lựa chọn theo phong cách (mặc dù tôi đang nghiêng về các tệp cấu hình, vì một khi bạn đã thiết lập một dịch vụ, tôi sẵn sàng đặt cược rằng nó sẽ không thay đổi nhiều).

• Mã mong đợi có vẻ gián tiếp hơn nhiều so với những gì bạn có thể quen thuộc. Sẽ có nhiều nơi thay vì nói "Làm điều này tiếp theo", bạn sẽ nói "Hỏi cấu hình cho những gì chúng ta phải làm tiếp theo, sau đó đi làm điều đó". Đó có thể là một vấn đề đau đầu về phát triển, nhưng bạn sẽ quen với nó.

• Tôi muốn giới thiệu một cấu trúc "Đây là những yếu tố phổ biến mà mọi người có thể muốn, và đây là những yếu tố riêng biệt được thiết kế bằng tay cho từng tiểu bang." Cuối cùng, việc xác định chính xác chức năng mặc định đó sẽ là một phần quan trọng trong việc làm việc với mã dễ dàng / khủng khiếp như thế nào trong tương lai. Hãy chuẩn bị để thực hiện một số tái cấu trúc khi bạn học được rằng nhiều thứ hơn bạn nghĩ cần phải được cấu hình.

• Luôn đảm bảo rằng mọi thông báo lỗi đến từ các thành phần tùy chỉnh xác định chính xác chúng đến từ đâu. Số lượng lớn các đường dẫn thực thi khác nhau có nghĩa là gỡ lỗi sẽ không có vấn đề gì; bất cứ điều gì bạn có thể làm để giảm số lượng săn trứng Phục sinh sẽ đáng giá hơn.

• Đầu tư thời gian để làm một bộ kiểm tra tự động tốt. Một bộ thử nghiệm tự động thực sự tốt. Điều này luôn luôn là thực hành tốt, nhưng đối với bạn, nó có thể có nghĩa là sự khác biệt giữa thành công và thất bại. Một lần nữa, đó là sự đa dạng của các đường dẫn thực thi; bất kỳ sửa đổi nào đối với mã chung sẽ khiến bạn dễ bị lỗi hiệu ứng cánh bướm trong các nhánh mà bạn không mong đợi. Bạn cần phải bắt những con bọ đó trước khi chúng được sản xuất.

Mặc dù cấu hình có thể giúp nó không giải quyết được tất cả các vấn đề của bạn nhưng nó có thể tạo ra những vấn đề mới.

Cho đến nay, cách tốt nhất theo kinh nghiệm của tôi là tạo ra một giải pháp thuê nhà có thể xử lý tất cả hoặc bất kỳ trạng thái nào (người thuê nhà)

Điều này sẽ yêu cầu cấu hình. tức là phần trăm thuế bán hàng theo tiểu bang nhưng cũng có mã điều kiện LegalMethodOfCalculatingWorkingHoursA vs B

Nếu ứng dụng của bạn được lưu trữ / trực tuyến, bạn có thể sử dụng phương pháp microservice theo mã có điều kiện nhưng một giải pháp ngoại tuyến sẽ phải gói tất cả các mô-đun tùy chọn và chọn giữa chúng.

Bạn sẽ tìm thấy một số mô-đun được sử dụng lại trên tất cả các tiểu bang, chẳng hạn như thuế bán hàng và một số luật điên chỉ được sử dụng trong một tiểu bang. Bạn cũng sẽ thấy rằng luật thay đổi theo thời gian. vì vậy các mô-đun được sử dụng sẽ thay đổi theo thời gian trong một trạng thái

Vì vậy, tôi sẽ đi với việc đặt tên theo chức năng chứ không phải là nhà nước.