Tôi nên tổ chức các thư mục của mình theo lĩnh vực kinh doanh hoặc theo lĩnh vực kỹ thuật?


19

Ví dụ: nếu tôi đang sử dụng một số kiến ​​trúc giống như MVC, tôi nên sử dụng cấu trúc thư mục nào:

domain1/
    controller
    model
    view
domain2/
    controller
    model
    view

Hoặc là:

controllers/
    domain1
    domain2
models/
    domain1
    domain2
views/
    domain1
    domain2

Tôi cố tình bỏ phần mở rộng tập tin để giữ cho câu hỏi này không biết ngôn ngữ.

Cá nhân, tôi muốn phân tách theo lĩnh vực kinh doanh (cảm giác ruột), nhưng tôi thấy rằng hầu hết / nhiều khung phân tách theo miền kỹ thuật. Tại sao tôi chọn cái này hơn cái kia?


2
các khung được nhắm mục tiêu vào các nhà phát triển, không phải cho người dùng doanh nghiệp. Các nhà phát triển dự kiến ​​sẽ thoải mái hơn với cách tiếp cận theo định hướng kỹ thuật và các khuôn khổ có tính đến điều đó - đó có thể là lý do cho những gì bạn quan sát
gnat

Câu trả lời:


15

Tôi nghĩ rằng điều này phụ thuộc vào dự án cụ thể.

Ví dụ: nếu các lĩnh vực kinh doanh khác nhau hoàn toàn độc lập với nhau, thì tôi sẽ tổ chức theo lĩnh vực kinh doanh.

Nhưng nếu có mã chia sẻ giữa các lĩnh vực kinh doanh, hay đúng hơn, các lĩnh vực kinh doanh là các biến thể khác nhau của cùng một cơ sở mã, thì việc tổ chức theo lĩnh vực kỹ thuật có vẻ hợp lý hơn. Và nếu bạn sử dụng bất kỳ loại ngôn ngữ hướng đối tượng nào, thì có lẽ bạn có thể phân lớp các bộ điều khiển chung, mô hình, v.v. trong các tệp dành riêng cho doanh nghiệp của bạn để làm cho chúng mỏng hơn.

Ngoài ra, còn có một khoảng giữa (vàng) giữa hai - loại bỏ mã được chia sẻ thành tên miền riêng của nó và sử dụng mã đó trong các miền khác. Điều này cung cấp cho bạn bố cục dựa trên cảm giác ruột của bạn, nhưng cho phép chia sẻ mã giữa các lĩnh vực kinh doanh.

Domain1              # This domain changes bits of standard MVC code
  controllers
  models
  views
Domain2              # this domain only modifies views, all else is standard
  views
Shared               # Here is the better part of code base
  controllers
  models
  views

Tái bút Tôi nghĩ rằng hầu hết các khung tổ chức theo miền kỹ thuật chỉ vì họ có xu hướng mong đợi rằng bạn trộn các miền kinh doanh khác nhau vào một dự án chỉ khi bạn đã chia sẻ mã và nếu không sẽ tạo các dự án riêng biệt.

CHỈNH SỬA:

Ví dụ: giả sử có một ứng dụng web xử lý kho của công ty. Ở dạng chung, điều này có thể áp dụng cho nhiều công ty, nhưng mỗi công ty có thể có một số chi tiết cụ thể không đáp ứng và cấm họ mua. Ví dụ: một trong số họ đã triển khai máy tính bảng cho xe nâng và cần có Chế độ xem đặc biệt cho họ trong khi một người khác muốn để sắp xếp các mục thành ba cấp độ thay vì mặc định là hai cấp độ.

Tất nhiên bạn có thể rẽ nhánh dự án cho mỗi công ty này. Nhưng nếu khung / ngôn ngữ cho phép, bạn có thể sử dụng phân lớp hoặc plugin, v.v. để tùy chỉnh các bit và phần của dự án chung theo nhu cầu của mọi khách hàng và sắp xếp chúng trong bố trí Miền doanh nghiệp.

Ví dụ: nếu dự án chung chỉ xuất sang JSON, thì Domain1 có thể phân lớp bộ điều khiển và khiến nó xuất ra các vấn đề phân phối gần đây.

Và nếu sau này bạn thấy rằng Domain1 có một thành phần cũng hợp lệ cho Domain2, bạn có thể trích xuất phiên bản chung của nó sang Shared.

Như bạn đã nói, nhiều khung tổ chức theo lĩnh vực kỹ thuật và đó là những gì tôi đã sử dụng cho đến bây giờ, chỉ vì FW lựa chọn của tôi làm cho việc này dễ dàng hơn. Nhưng với một ít (hoặc rất nhiều) mỡ khuỷu tay, tôi nghĩ rằng tôi có thể viết lại các đường dẫn bao gồm để hỗ trợ bố cục Miền doanh nghiệp.


Tôi nghĩ ý tưởng này rất hay, nhưng tôi không thể tưởng tượng được một ví dụ thực tế. Bạn có thể cho một cái đơn giản nhưng khai sáng?
Florian Margaine

@FlorianMargaine - Tôi sẽ cho bạn một ví dụ thực tế. Trang web bất động sản. Ở công việc cuối cùng của chúng tôi, chúng tôi đã bán một số trang web bất động sản cho nhiều khách hàng. Chúng tôi đã có một cơ sở dữ liệu tập trung cho tất cả hơn 50 khách hàng. Mỗi quản trị viên back-end đã sử dụng một bộ mô-đun được chia sẻ. Mỗi mặt khách hàng sử dụng hình ảnh độc đáo và điều hướng. Mỗi trang tìm kiếm và truy sâu các trang được sử dụng các mô-đun được chia sẻ trừ trường hợp khách hàng muốn các tính năng một lần. Đối với những người một lần, chúng tôi tách mã và đưa cho họ mô-đun riêng. (Nhược điểm: Việc nâng cấp phải được thực hiện trong các mô-đun chung và được nhân đôi trong các mô-đun một lần)
Michael Riley - AKA Gunny

8

Tôi nghĩ thật tuyệt vời khi hỏi, "tôi có khả năng thêm gì một cách thường xuyên, nhiều lĩnh vực hơn hoặc nhiều bộ phận kỹ thuật hơn?" Sau đó, bất kể câu trả lời là gì, đặt nó ở cấp cao nhất.

Trong hầu hết các trường hợp, kiến ​​trúc kỹ thuật của bạn sẽ củng cố nhanh hơn miền của bạn. Điều đó có nghĩa là bạn nên tổ chức theo tên miền trước, sau đó theo thành phần kiến ​​trúc. Lý do là khi một cái gì đó trong một miền thay đổi, bạn có thể phải thêm hoặc thay đổi nhiều thành phần kỹ thuật trong miền đó, nhưng hy vọng đó là nội địa hóa và không tràn vào các tên miền khác.

Nếu bạn thay đổi khung GUI, điều đó có nghĩa là các thay đổi của bạn sẽ tràn ra toàn bộ ứng dụng, nhưng một lần nữa, bạn hiếm khi thay đổi khung GUI, nhưng bạn luôn thay đổi logic miền của mình.

Giữ mọi thứ cùng nhau nếu chúng có khả năng thay đổi cùng một lúc.


Lời khuyên tốt nhất, nhưng tôi không thấy cách dự đoán loại tên miền nào tôi sẽ thêm nhiều nhất.
Florian Margaine

Câu cuối cùng đinh nó.
Hakan Deryal

@FlorianMargaine - Tôi không nghĩ "loại" vấn đề tên miền. Nếu bạn thêm tên miền nhiều hơn bạn thêm "thứ" kỹ thuật mới thì hãy nhóm mọi thứ theo tên miền trước.
Scott Whitlock

3

Có một cách khác và đó là di chuyển các phần riêng biệt trong plugin. CakePHP làm điều đó chẳng hạn. Nó sẽ cho phép bạn tạo các phần MVC hoàn chỉnh có thể sử dụng lại mà bạn có thể sắp xếp theo bất kỳ logic nào bạn muốn.

Ứng dụng chính của bạn sẽ chỉ sử dụng chúng và liên kết với chúng.

Về cơ bản câu hỏi của bạn cũng là về sự gắn kết và khớp nối. Bạn muốn các bộ phận riêng biệt làm việc độc lập nhất có thể. Bằng cách đó bạn có được mã kiểm tra và có thể sử dụng lại.

Cân nhắc điều đó: Nếu bạn tách ra theo tên miền, bạn sẽ sử dụng lại các phần trong ứng dụng của mình như thế nào? Ví dụ: lấy một webshop: một yêu cầu xuất hiện cho / đơn hàng / lượt xem / 1 vì vậy bạn cần hiển thị thứ tự nr. 1. Chuyển đến / đơn hàng / bộ điều khiển / order_controll Nếu bạn tách biệt tên miền theo sản phẩm và đơn đặt hàng, bạn sẽ cần các phần của "miền" khác.

Ở đó bạn có thể bắt đầu giao thoa mọi thứ nhưng có khả năng mọi thứ trong hầu hết các doanh nghiệp chỉ là quá gắn kết. Nếu bạn thực hiện các phương pháp kỹ thuật. Ví dụ, bạn có thể có một đơn đặt hàng xử lý plugin. Bạn đặt các đối tượng Sản phẩm cho nó từ ứng dụng trung tâm của bạn. Bằng cách đó, bạn có thể kiểm tra plugin một cách dễ dàng, chỉ cần tạo một số đối tượng Sản phẩm có tên và giá và gửi nó vào.

Các plugin sẽ làm chính xác những gì nó cần làm. Nó sẽ phụ thuộc vào đầu vào của nó chứ không phụ thuộc vào "các bộ phận / miền / khu vực" khác.


Ý tưởng tốt. Về cơ bản, đó là câu trả lời từ trên xuống. Tôi đặt mã được chia sẻ lên hàng đầu và về cơ bản được cắm vào các chi tiết cụ thể của Miền. Bạn đặt Tên miền ở trên cùng và cắm Mã được chia sẻ. Tôi nghĩ cả hai đều là những cách tiếp cận tốt như nhau về khả năng khử ghép và khả năng kiểm tra.
Laas

2

Microsoft ASP.Net MVC 3 có khái niệm "Khu vực". Khi bạn giới thiệu "Khu vực" vào dự án MVC của mình, họ sẽ chia nó ra như sau:

area1/
   models
   views
   controllers
area2/
   models
   views
   controllers

Tôi thấy điều này là khá tự nhiên. Một khu vực là một "khối lớn" của một dự án và làm việc trong một đơn vị khép kín chỉ có ý nghĩa rất lớn.

Chúng tôi đã sử dụng các không gian tên để khớp, FWIW.


2
Cảm ơn bạn đã đóng góp, nhưng làm thế nào mà trả lời câu hỏi của tôi? (So ​​sánh cả hai giải pháp)
Florian Margaine

@FlorianMargaine: Tôi đang minh họa cách Microsoft đã làm điều đó, với giả định (có thể là thiếu sót) rằng họ đã nỗ lực rất nhiều về kỹ thuật để chọn cách hợp lý hơn. Hy vọng nó cho một số đầu vào.
gahooa

Ok, nhưng đó là cách định hướng kinh doanh mà tôi đã thể hiện trong câu hỏi của mình ...
Florian Margaine

1

Từ kinh nghiệm cá nhân của tôi với một cửa hàng web bao gồm 300 000 dòng mã, tôi sẽ luôn tổ chức theo lĩnh vực kinh doanh. Theo cách này, bạn không chỉ có thể có được một cái nhìn tổng quan nhanh về tất cả các lớp có liên quan khi bạn làm việc trên một khu vực chức năng, trong Java, bạn cũng có thể sử dụng khả năng hiển thị gói.

Một số chi tiết cho những người quan tâm: Khi dự án được bắt đầu 5 năm trước, các nhà phát triển đã tạo ra cấu trúc gói sau:

com
  example
    web
      struts
        action
        form
      shared
      functionality1
      functionality2

Mỗi chức năng của cửa hàng như giỏ hàng, tìm kiếm sản phẩm, v.v ... bao gồm một số hành động, mỗi hành động có lớp biểu mẫu riêng (cấu trúc được ủy quyền bởi khung MVC). Những gì chúng tôi đã kết thúc là hơn 200 lớp trong gói hành động, mỗi lớp tách biệt hoàn toàn với lớp biểu mẫu liên kết của chúng. Điều tồi tệ hơn là các hành động không thực hiện quá nhiều logic, nhưng gọi các dịch vụ dành riêng cho chức năng nằm trong gói khác.

Tôi đã gợi ý và thuyết phục nhóm rằng chúng ta nên chuyển sang tổ chức các gói theo lĩnh vực kinh doanh. Lý do rất đơn giản: nếu bạn thực sự muốn xem danh sách tất cả các hành động, bạn có thể chỉ cần mở chế độ xem phân cấp loại của bất kỳ IDE phong nha nào. Tuy nhiên, những gì IDE không thể làm là suy ra miền kinh doanh mà một lớp thuộc về. Hơn nữa, cách tiếp cận đó cho phép bạn chỉ công khai những lớp đó là cần thiết cho một số chức năng, giữ cho phần còn lại hiển thị gói.


0

Tôi đồng ý rằng nhiều khung phân tách theo miền kỹ thuật và vì vậy tôi thường bắt đầu theo cách này khi sử dụng khung mới. Tuy nhiên, tôi luôn giải quyết việc sử dụng miền doanh nghiệp làm cấp chính của tổ chức thư mục.

Cá nhân, tôi nghĩ rằng việc giữ Bộ điều khiển Foo và Kho lưu trữ Foo của tôi dễ dàng hơn nhiều so với việc chuyển qua lại giữa thư mục của Bộ điều khiển và thư mục của Kho lưu trữ như tôi thường xuyên phải làm việc trên cả hai khi thêm các tính năng xung quanh Foo. Trong các dự án lớn hơn, điều này thậm chí còn quan trọng hơn vì khoảng cách giữa các thư mục kỹ thuật có thể rất lớn và trở thành một sự lãng phí thời gian đáng chú ý trong khi phát triển.

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.