DDD Khi nào tôi nên tạo một đối tượng miền và một đối tượng bền vững thay vì sử dụng đối tượng persistence làm đối tượng miền?

Question

Khi tôi làm việc với sự hiểu biết về thiết kế điều khiển tên miền, tôi thấy rằng tôi có quy tắc có vẻ hoạt động, mặc dù tôi muốn xem liệu nó có quá mức cần thiết hay không và cũng muốn xem các quan điểm khác của cùng một tình huống.

Câu hỏi của tôi là: "Khi nào mô hình miền và mô hình bền vững được chứa trong các đối tượng riêng biệt?" Ngôn ngữ tôi chọn là Java vào lúc này và tôi đang sử dụng mô hình kho lưu trữ của Dữ liệu Mùa xuân.

Tôi thấy ba câu trả lời chính cho câu hỏi của mình.

1. Luôn sử dụng các đối tượng tên miền riêng biệt từ các đối tượng kiên trì.
2. Chỉ sử dụng các đối tượng tên miền riêng biệt khi đặt các phương thức miền (hành vi) đối với các đối tượng bền bỉ là không thực tế.
3. Sử dụng các đối tượng bền vững làm đối tượng miền trong mọi trường hợp.

Để đặt câu hỏi về DDD, tôi thấy rằng tôi phải sử dụng ngữ cảnh bị ràng buộc ví dụ vì tôi chưa biết đủ về DDD để hỏi theo cách trừu tượng hơn.

Đây là bối cảnh giáp minh họa của tôi: nói rằng tôi có một hệ thống pháp điển hóa pháp luật với các quy tắc kinh doanh sau:

1. Mỗi pháp luật về những cuốn sách phải được phân loại.
2. Mỗi luật có một số nhận dạng với hai phần, một tiền tố số hóa mã hóa và hậu tố coassign mã hóa. (Ví dụ: 100-0100, 599-2030).
3. Có nhiều khu vực pháp lý đang sử dụng hệ thống mã hóa luật và họ có thể tự tạo các đồng ký nhưng các tiền tố mã hóa toàn cầu và phải giống nhau trên tất cả các khu vực pháp lý để tạo điều kiện so sánh chung.
4. các tiền tố số được mã hóa được nhóm thành các danh mục mã hóa rộng. loại pháp điển hóa có một dãy số, chẳng hạn như 100-199, 200-299, 700-799, vv

Để diễn tả bối cảnh bị chặn điều này như một mô hình bền bỉ tôi đã điều sau đây:

table: codification 
fields: chart_code, prefix, coassign, codification_category 

table: codification_chart 
fields: chart_code, jurisdiction_description 

table: codification_category 
fields: category, low_category_number, high_category_number, description 

table: global_codification 
fields: prefix, coassign, codification_category 

Tôi biết, tôi nên bắt đầu từ mô hình miền trước tiên. Tôi có một mô hình bền bỉ và một mô hình miền

Trong mô hình miền của tôi, tôi có ba miền đối tượng

public Codification { 
    private String prefix, coassign; 
    codificationCategory codificationCaegory; // an enum type 
    public Codification(...) { // set private vars } 
    // getters for private variables 
} 

public CodificationChart { 
    private List<Codification> chartCodifications = new ArrayList<>(); 
    private String chartCode; 
    // public constructor to initialize private variables 
    // getters for private variables 
    public Codification addCodificationToChart(Codification){...} 
    public void removeCodificationFromChart(Codification){...} 
    public boolean checkCodificationInChart(Codification){...} 
} 

public enum CodificationCategory { 
    CIVIL, CRIMINAL, PROPERTY, CORPORATE, FAMILY, CONSUMER, ETHICS, BANKRUPTCY; 
} 

ORM Đối tượng:

JPA Mappings of the tables mentioned earlier with the "Entity" suffix added to their table names. 
They are omitted for brevity. 
Each one contains getters and setters like JPA Pojos do. 
If someone asks for the Persistence objects code I will post it. 

Điểm duy nhất mà đối tượng tên miền của tôi biết về mô hình persistence nằm trong đối tượng nhà máy của tôi CodificationChartFactory, trong đó có các giao diện kho lưu trữ mà tôi đang sử dụng để tương tác với các đối tượng ORM được đề cập trước đó. Nhà máy này là phần duy nhất của miền sử dụng các kho lưu trữ kiên trì, do đó phần duy nhất tương tác với lớp kiên trì.

Tạo mô hình miền riêng biệt ở đây có nỗ lực lãng phí không? Tôi có thể thấy làm thế nào tôi có thể đặt các hành vi CodificationChart của tôi trên một đối tượng Persistence. Nó chỉ bằng cách nào đó cảm thấy sai lầm khi đặt những hành vi đó vào một đối tượng kiên trì, chỉ có công việc là lấy một bản ghi từ cơ sở dữ liệu.

Tôi chắc chắn sẽ được sửa chữa.

Answer 1

Cả hai cách tiếp cận đều đúng và là vấn đề về hương vị từ quan điểm thiết kế. Một số người không muốn đối tượng miền của họ hoàn toàn liên quan đến sự kiên trì và tạo thêm một lớp đối tượng Entity ... một số người không nghĩ đây là vấn đề lớn và vui lòng tiếp tục và sử dụng miền các đối tượng như các đối tượng kiên trì.

Cá nhân (và chủ quan), tôi nghĩ rằng việc sử dụng JPA và có thêm một lớp đối tượng Thực thể là cách tiếp cận sai. Mục đích của các ORM như Hibernate là trở thành cầu nối giữa các mô hình Object và Relational (tôi biết nó có tên :). Tôi nghĩ cách tiếp cận tốt hơn, trong trường hợp người ta muốn giữ mọi thứ tách biệt, là sử dụng cái gì đó như mybatis hoặc SQL đơn giản, nhưng chắc chắn là không phải JPA ... nếu không nó chỉ thêm độ phức tạp vì lợi ích phức tạp (JPA không phải là khung dễ dàng nhất để tìm hiểu)

Tôi rất vui khi được kết hợp và chú thích các đối tượng miền của mình. Như tôi biết nó làm cho sự kiên trì dễ dàng hơn để quản lý ... nhưng đồng thời, tôi cảm thấy rất thoải mái với Hibernate/JPA và đã sử dụng nó trong 10 năm :).

Tôi đã có một câu hỏi rất giống 3 năm trước, mà tôi đã đăng trên trang lập trình viên - Do ORMs enable the creation of rich domain models?