Cấu trúc ứng dụng Java: Phân chia ngang và dọc

Có một chút tranh luận về cấu trúc dự án bắt đầu (sử dụng Maven / Eclipse) cho một ứng dụng Java lớn.

Lựa chọn 1:

entities (i.e. the whole database using Hibernate classes-first)
services (i.e. sets of read/write operations on the entities)
app (perhaps split up more further down the line)

Lựa chọn 2:

area1-entities
area1-services
area1-app
area2-entities
area2-services
area2-app
...
(where area1, area2 etc. are functional areas of the system)

Tùy chọn 2 rõ ràng sẽ dẫn đến rất nhiều dự án / mô-đun Maven và có nghĩa là các lớp sẽ tạo cơ sở dữ liệu được phân phối giữa nhiều dự án. Bất cứ ai có thể tư vấn ưu / nhược điểm của từng phương pháp?

Tôi sẽ đề nghị không làm.

Cố gắng thực thi một lớp kỹ thuật với cấu trúc gói dẫn đến rất nhiều vướng mắc trong ứng dụng của bạn. Chưa kể đến việc chúng tôi rất cố gắng để che giấu mọi thứ đằng sau một giao diện dịch vụ và điều đầu tiên chúng tôi làm (chủ yếu là do đóng gói) là làm mọi thứ a public class. Điều này trở nên đau đớn khi có sự phân tách kỹ thuật giữa a x.y.z.servicevà x.y.z.repositorygói, bây giờ mọi thứ đều có thể truy cập vào kho lưu trữ. Boom ở đó đóng gói của bạn bên trong lớp dịch vụ.

Thay vào đó, bạn nên theo một cách tiếp cận dựa trên chức năng và hành tây hơn ( kiến trúc sạch , kiến trúc lục giác ). Điều này cũng phù hợp với Nguyên tắc Trách nhiệm duy nhất (khi áp dụng cho một gói) và cũng phù hợp với các nguyên tắc đóng gói

1. Những thứ thay đổi cùng nhau được đóng gói cùng nhau
2. Những thứ được sử dụng cùng nhau được đóng gói cùng nhau

Oliver Gierke đã viết một bài đăng hay về các thành phần đóng gói cùng nhau trong Java. Simon Brown đã viết một câu chuyện tổng quát hơn về chủ đề này.

Tôi sẽ cố gắng cho một cấu trúc gói lõi như sau để giữ cốt lõi của ứng dụng của bạn:

x.y.z.area1
x.y.z.area2

Bây giờ, nếu bạn có một giao diện web mà bạn thêm, ví dụ, một webgói con, cho dịch vụ web một wshoặc restgói chỉ giữ điều đó. Về cơ bản nó kết nối với lõi.

x.y.z.area1.web
x.y.z.area1.ws
x.y.z.area2.rest

Bây giờ bạn có thể xem xét sử dụng lại các đối tượng từ bên trong lõi của mình vào các lớp khác, nhưng IMHO tốt hơn là sử dụng một miền cụ thể cho lớp đó. Như, giống như với ánh xạ Object to SQL, (thường) có sự không phù hợp trong những gì chúng ta muốn hiển thị trên màn hình hoặc sử dụng như XML trong dịch vụ web và cách thức logic nghiệp vụ được triển khai. Tùy thuộc vào mức độ phức tạp của tên miền doanh nghiệp và web, bạn có thể coi chúng là các miền vấn đề riêng biệt để giải quyết cần phải kết nối, về cơ bản là 2 bối cảnh bị ràng buộc khác nhau .

Để sử dụng trích dẫn từ tài nguyên CQRS

Không thể tạo ra một giải pháp tối ưu để tìm kiếm, báo cáo và xử lý các giao dịch sử dụng một mô hình duy nhất.

Đừng cố gắng đặt mọi thứ vào một mô hình (tên miền) duy nhất, tách biệt các trách nhiệm. Bạn có thể kết thúc với nhiều lớp (nhỏ hơn) nhưng phân tách rõ ràng hơn giữa các lớp của ứng dụng của bạn.

Lưu ý cuối cùng

Hãy nhớ rằng việc tạo ra một kiến ​​trúc là quyết định đánh đổi một giải pháp khác. Nó phụ thuộc nhiều vào độ phức tạp của miền và chủ yếu nên được điều khiển bởi các yêu cầu chức năng của ứng dụng của bạn. Tuy nhiên, nó bị ảnh hưởng bởi các hạn chế phi chức năng (hiệu suất, bảo mật) và môi trường (ngôn ngữ để sử dụng, nền tảng, kinh nghiệm). Và kiến ​​trúc, giống như mã hóa, không bao giờ kết thúc mỗi yêu cầu mới có thể (và có thể nên?) Dẫn đến việc thiết kế lại ứng dụng.

Khước từ

Có, tôi cũng đã cố gắng đặt mọi thứ trong một mô hình duy nhất và có, tôi cũng đã thử sử dụng một phân tách kỹ thuật trong các ứng dụng của mình. Tuy nhiên, sau một vài năm kinh nghiệm trong việc tạo lớp ứng dụng vướng víu (ban đầu có vẻ là một ý tưởng tốt, sau đó ứng dụng bắt đầu phát triển ...) Tôi nghĩ rằng phải có một cách khác.

Liên kết

1. Kiến trúc sạch, chú Bob Martin
2. Kiến trúc lục giác (còn gọi là Cổng và Bộ điều hợp), Alistair Cockburn
3. Rất tiếc kiến ​​trúc của tôi đã đi đâu, Oliver Gierke
4. Nguyên tắc của OOD, chú Bob Martin
5. Những sai lầm khi áp dụng DDD, Udi Dahan
6. Bối cảnh bị ràng buộc, Martin Fowler
7. Kiến trúc mã hóa theo phong cách kiến ​​trúc, Simon Brown

Sách

1. Phát triển phần mềm hướng đối tượng, được hướng dẫn bởi các thử nghiệm
2. Kiến trúc ứng dụng Java: Các mô hình mô đun với các ví dụ sử dụng OSGi (Dòng Robert C. Martin)
3. Thiết kế hướng tên miền: Giải quyết sự phức tạp trong trung tâm của phần mềm
4. Kiến trúc phần mềm cho nhà phát triển
5. Triển khai thiết kế hướng tên miền