1. Giới thiệu bối cảnh

Nhóm của chúng tôi đã liên tục thúc đẩy việc quản trị có hệ thống các hệ thống kinh doanh và trong quá trình đó, chúng tôi đã phát triển dự án giàn giáo DDD của riêng mình. Dự án giàn giáo là một phần quan trọng của quy trình quản trị có hệ thống. Nó có hai chức năng:

(1) Các dự án mới có thể được thống nhất và chuẩn hóa;

(2) Hướng dẫn chuyển đổi DDD của các dự án cũ.

Bài viết này chủ yếu phân loại và tóm tắt các tiêu chuẩn mã hóa và các vấn đề gặp phải khi sử dụng giàn giáo DDD.

2. Cơ sở lý thuyết về giàn giáo

Có nhiều loại kiến ​​trúc ứng dụng liên quan đến DDD, chẳng hạn như kiến ​​trúc bốn lớp, kiến ​​trúc củ hành, kiến ​​trúc lục giác, kiến ​​trúc sạch, v.v. Các kiến ​​trúc ứng dụng này có những đặc điểm và sự khác biệt riêng. Nhưng ý tưởng tổng thể của họ là tương tự nhau, chủ yếu thông qua việc phân lớp để đạt được sự tách biệt về chức năng và mối quan tâm. Mục tiêu đạt được là lớp miền không phụ thuộc vào bất kỳ triển khai bên ngoài nào khác, do đó logic nghiệp vụ cốt lõi có thể được đảm bảo sạch sẽ và ổn định.

Hình bên trái là sơ đồ của một kiến ​​trúc sạch sẽ. Hình bên trái hiển thị các lớp. Hình bên phải hiển thị tần suất thay đổi và mức độ trừu tượng của từng lớp. Kiến trúc sạch chủ yếu được chia thành 4 lớp:

(1) Lớp Frameworks&Drivers: Lớp này đại diện cho các hệ thống bên ngoài mà hệ thống phụ thuộc vào, chẳng hạn như cơ sở dữ liệu, bộ đệm, trang giao diện người dùng, v.v. Lớp này thay đổi thường xuyên nhất và cần được tách biệt khỏi logic nghiệp vụ cốt lõi của chúng tôi.

(2) Lớp Bộ điều hợp giao diện: Lớp này là lớp thích ứng, chịu trách nhiệm chính cho việc thích ứng các hệ thống bên ngoài và hệ thống kinh doanh nội bộ. Chức năng chính của lớp này là thích ứng và chuyển đổi giao thức của các hệ thống bên ngoài và hệ thống nội bộ.

(3) Quy tắc nghiệp vụ ứng dụng: Lớp quy tắc nghiệp vụ ứng dụng có thể được hiểu là lớp ca sử dụng. Lớp này cho biết các chức năng và dịch vụ ở cấp độ ca sử dụng mà toàn bộ ứng dụng có thể cung cấp. Lớp này cũng là lớp điều phối các quy tắc nghiệp vụ cốt lõi ở lớp 4.

(4) Quy tắc kinh doanh doanh nghiệp: Lớp này là lớp logic nghiệp vụ cốt lõi. Lớp này không chứa bất kỳ nội dung nào liên quan đến công nghệ, chỉ có logic nghiệp vụ.

3. Giới thiệu và sử dụng giàn giáo

Sử dụng lệnh sau:

                        
                          mvn archetype:generate -DarchetypeGroupId=com.jd.jr.cf -DarchetypeArtifactId=ddd-archetype -DarchetypeCatalog=local -DarchetypeVersion=0.0.1-SNAPSHOT -DinteractiveMode=false -DgroupId=com.jd.demo.test //Bắt đầu từ dòng này và cần sửa đổi nó theo tên dự án -DartifactId=demo-test -Dversion=1.0.0 -Dpackage=com.jd.demo.test -DappName=demo-test -s D:/git /settings.xml / /tệp cấu hình git cục bộ


                        
                      

Cấu trúc dự án được tạo ra như sau:

                        
                          |--- bộ điều hợp -- ứng dụng lớp bộ điều hợp và tương tác và thích ứng ứng dụng bên ngoài --- bộ điều khiển -- lớp điều khiển, triển khai các giao diện trong API --- trình biên dịch mã, DTO và mô hình miền Chuyển đổi |- -- impl -- Triển khai giao diện trong lớp giao thức | -- kho lưu trữ -- Lớp lưu trữ -- Trình biên dịch mã -- Chuyển đổi trình biên dịch mã, PO và mô hình miền | Triển khai giao diện lưu trữ trong lớp miền | --- rpc -- Lớp RPC, việc triển khai giao diện bên ngoài dựa vào cổng trong lớp Miền, gọi giao diện RPC từ xa --- tác vụ, chủ yếu là bộ chuyển đổi | để lập kế hoạch tác vụ |--- api -- giao diện api được hiển thị bởi ứng dụng lớp giao thức ứng dụng |--- boot -- khung ứng dụng, trình điều khiển lớp khởi động, v.v. --- aop -- các khía cạnh | -- cấu hình | Lớp khởi động |--- ứng dụng -- lớp ứng dụng | --- trường hợp -- dịch vụ ứng dụng --- miền -- lớp miền --- mô hình -- đối tượng miền | tổng hợp | -- thực thể -- Thực tế| |--- vo -- Đối tượng giá trị |--- dịch vụ -- Dịch vụ tên miền |--- nhà máy -- Nhà máy, đối với một số Đối tượng phức tạp, bạn có thể sử dụng nhà máy Để xây dựng | |--- cổng -- cổng, nghĩa là giao diện | |--- sự kiện -- sự kiện miền |--- ngoại lệ -- đóng gói ngoại lệ |--- khả năng -- khả năng miền |--- phần mở rộng -- điểm mở rộng --- impl -- điểm mở rộng | |--- truy vấn -- lớp truy vấn, dịch vụ đọc được đóng gói |--- mô hình -- mô hình truy vấn |--- dịch vụ -- dịch vụ truy vấn


                        
                      

Sơ đồ kiến ​​trúc lớp tổng thể như sau:

4. Thông số kỹ thuật mã hóa giàn giáo

1. Thông số kỹ thuật mã hóa mô-đun Api:

• Mô-đun Api là mô-đun được sử dụng riêng để xác định giao diện bên ngoài, vì vậy mô-đun này chỉ chứa các định nghĩa giao diện và định nghĩa tham số đầu vào và đầu ra, đồng thời cố gắng không dựa vào các gói khác.
• Lớp định nghĩa giao diện trong API kết thúc bằng xxxxResource (hoặc xxxxService). Thông số kỹ thuật này hoàn toàn phù hợp với các ứng dụng cũ hơn.
• Cố gắng không sử dụng kiểu nguyên tử (Loại nguyên thủy) trong Java cho các tham số đầu vào của giao diện Api. Các tham số đầu vào cần được xác định thành các lớp riêng biệt. Tốt nhất là kế thừa từ lớp BaseRequest hiện có.
• Các tham số của giao diện Api sử dụng thống nhất các lớp chung để bao bọc các kiểu trả về thực.
• Các lớp tham số đến và đi đều kết thúc bằng DTO.
• Cố gắng không sử dụng các biến thành viên thuộc loại giá trị liệt kê trong các tham số đến và đi.

2. Thông số kỹ thuật mã hóa mô-đun Bộ điều hợp/Bộ điều khiển:

• Trong lớp này, cần chuyển đổi DTO của các tham số đến và đi và các đối tượng VO/DO của lớp nghiệp vụ.
• Lớp này không được chứa bất kỳ logic nghiệp vụ nào, chỉ chuyển đổi tham số và logic xác minh độc lập với nghiệp vụ.
• Logic của lớp bộ nhớ đệm giá trị trả về giao diện có thể được triển khai trong mô-đun này, vì hành động này không chứa logic nghiệp vụ.

3. Thông số kỹ thuật mã hóa mô-đun ứng dụng:

• Các lớp trong mô-đun này đều kết thúc bằng Case.
• Lớp này chủ yếu sắp xếp logic kinh doanh cơ bản. Định nghĩa cổng của lớp Miền có thể được gọi trực tiếp. Các cuộc gọi dịch vụ tên miền chéo cũng có thể được thực hiện trong mô-đun này.
• Lớp này có thể gọi trực tiếp dịch vụ Kho lưu trữ được xác định trong mô-đun Miền.
• Xử lý giao dịch: Nếu logic nghiệp vụ trên nhiều tập hợp cần được đặt trong một giao dịch thì giao dịch đó cần phải được mở và gửi ở lớp này.

4. Thông số kỹ thuật mã hóa lớp miền:

• Việc đặt tên DomainService được gắn liền với Dịch vụ.
• Các lớp thực thể được đặt tên không có hậu tố. Định nghĩa của lớp đối tượng giá trị đều kết thúc bằng VO.
• Các giao diện được xác định trong Kho lưu trữ và Cổng có thể được gọi trong logic DomainService.
• DomainService có thể hoạt động trên nhiều tập hợp, thực thể và đối tượng giá trị.
• Các lớp thực thể thực thể có thể có hàm tạo, hàm tạo và hàm getter. Không trực tiếp giải phóng các bộ cài đặt của tất cả các thuộc tính để ngăn mã doanh nghiệp sửa đổi các thuộc tính của thực thể theo ý muốn.
• Khi viết logic nghiệp vụ, bạn cần tuân thủ nguyên tắc: đặt logic nghiệp vụ trước trong Entity và VO, sau đó là tổng hợp và cuối cùng là DomainService.
• Nguyên tắc đảo ngược phụ thuộc: Các giao diện bên ngoài mà lớp Miền phụ thuộc phải được xác định trong gói cổng của mô-đun Miền. Lớp Miền chỉ định hướng lập trình giao diện và không dựa vào các lớp triển khai giao diện.

5. Thông số kỹ thuật mã hóa bộ chuyển đổi/kho lưu trữ và mô-đun Rpc:

• Trong lớp triển khai Kho lưu trữ, đối tượng DO trong tham số giao diện cần được chuyển đổi thành đối tượng PO trước khi gọi bộ lưu trữ cơ sở dữ liệu.
• Mối quan hệ giữa Kho lưu trữ và tổng hợp là mối quan hệ một đối một. Kho lưu trữ có tổng hợp tương ứng duy nhất.
• Nếu bạn cần bắt đầu một giao dịch trong Kho lưu trữ, bạn có thể bắt đầu giao dịch trong lớp triển khai Kho lưu trữ.
• Tốt nhất là lớp Rpc xác định đối tượng lớp chống ăn mòn cho các tham số đi và đến của giao diện bên ngoài và tên phải kết thúc bằng DTO.

5. Câu hỏi và giải pháp thường gặp

**Q1, **Gói jar do mô-đun Api cung cấp có cần tham chiếu gói jar của các ứng dụng khác không?

Câu trả lời 1: Trong một số trường hợp, tham số đầu vào của giao diện Api của ứng dụng A cần tham chiếu các lớp trong gói của ứng dụng khác. Ví dụ: ứng dụng A gửi một sự kiện và ứng dụng B cung cấp giao diện để xử lý sự kiện đó. Ứng dụng B có cần tham chiếu lớp định nghĩa sự kiện trong gói của ứng dụng A không? Lý tưởng nhất là ứng dụng B nên xác định lớp riêng của nó để ứng dụng B không phụ thuộc vào các gói của ứng dụng A.

**Q2, **Gói Api có thể chứa định nghĩa của một lớp liệt kê không?

Câu trả lời 2: Tốt nhất là không để lộ các định nghĩa giá trị liệt kê nội bộ trong gói Api. Vì giá trị liệt kê cần được xác định và sử dụng trong Domain module nên không phù hợp để lộ ra bên ngoài dưới dạng jar package. Nếu thực sự cần phải đưa nó ra các ứng dụng bên ngoài (ví dụ: để cho phép người gọi giao diện biết một cách thuận tiện những giá trị nào trong các tham số đầu vào), thì định nghĩa của lớp liệt kê có thể được đặt trong cùng một định nghĩa chung. bưu kiện. Bằng cách này, cả mô-đun Miền và gói jar được cung cấp bên ngoài đều có thể tham chiếu gói chung.

**Q3. **Việc lưu trữ dữ liệu có cần sử dụng số phiên bản thống nhất không?

Câu trả lời 3: Đối với các ứng dụng mới, tốt nhất nên sử dụng số phiên bản hợp nhất để khi cập nhật cơ sở dữ liệu, số phiên bản có thể được sử dụng thống nhất dưới dạng khóa lạc quan. Tuy nhiên, đối với các hệ thống cũ, chi phí cho việc kích hoạt số phiên bản tương đối cao, vì tất cả các điểm thực hiện thay đổi đối với các thực thể cần phải được sắp xếp và tất cả các điểm đều phải sử dụng số phiên bản một cách thống nhất. Vì vậy, bạn nên quyết định có nên sử dụng nó theo tình hình hay không.

Q4. Đối với một số doanh nghiệp định hướng quy trình, giao diện rpc bên ngoài thường được gọi. Nếu một đối tượng lớp chống ăn mòn được thêm vào mỗi giao diện rpc, hiệu quả phát triển sẽ giảm. Có thể không xác định đối tượng lớp chống ăn mòn?

Câu trả lời 4: Tốt nhất là xác định các đối tượng lớp chống ăn mòn, điều này có thể làm giảm một số hiệu quả phát triển trong thời gian ngắn, nhưng từ góc độ dài hạn và tiêu chuẩn mã, điều đó vẫn có giá trị.

Tác giả: Công nghệ Jingdong Shi Jijun.

Nguồn: JD Cloud Developer Community Vui lòng ghi rõ nguồn khi tái bản.

Cuối cùng, bài viết về [Thực hành] Tiêu chuẩn mã hóa và giàn giáo DDD kết thúc tại đây. Nếu bạn muốn biết thêm về [Thực hành] Tiêu chuẩn mã hóa và giàn giáo DDD, vui lòng tìm kiếm các bài viết CFSDN hoặc tiếp tục duyệt các bài viết liên quan. blog trong tương lai! .