Cách tiếp cận DDD với các hoạt động CRUD cơ bản trong một ứng dụng tập trung vào miền phức tạp

Công ty của tôi đang viết lại ứng dụng web của chúng tôi từ đầu. Đây là một ứng dụng cấp doanh nghiệp lớn với một lĩnh vực phức tạp trong ngành tài chính.

Chúng tôi đang sử dụng ORM (khung thực thể) để duy trì.

Về bản chất, một nửa ứng dụng của chúng tôi tập trung vào việc thu thập dữ liệu thô từ người dùng, lưu trữ và sau đó, nửa còn lại của ứng dụng chứa hầu hết logic miền thực tế của chúng tôi lấy dữ liệu thô đó để tạo ra hình ảnh miền khác với những gì ban đầu đầu vào thô và chuyển nó vào một động cơ calc, chạy calcs và phun ra kết quả, sau đó được hiển thị cho người dùng.

Trong cách tiếp cận DDD bằng cách sử dụng các lớp, có vẻ như các hoạt động CRUD đi qua lớp miền. nhưng ít nhất trong trường hợp của chúng tôi, điều này dường như không có ý nghĩa.

Khi người dùng vào màn hình chỉnh sửa để thay đổi tài khoản đầu tư, các trường trên màn hình là các trường chính xác được lưu trữ trong cơ sở dữ liệu, không phải là đại diện miền được sử dụng sau này để tính toán. Vậy tại sao tôi lại tải đại diện miền của tài khoản đầu tư khi màn hình chỉnh sửa cần đại diện cơ sở dữ liệu (đầu vào thô)?

Sau khi người dùng nhấp vào "Xong" trên màn hình tài khoản đầu tư và POST được thực hiện cho bộ điều khiển, bộ điều khiển hiện có khá nhiều đại diện cơ sở dữ liệu chính xác của tài khoản đầu tư mà nó cần lưu. Nhưng vì một số lý do, tôi phải tải đại diện miền để sửa đổi thay vì chỉ ánh xạ trực tiếp mô hình của bộ điều khiển vào mô hình cơ sở dữ liệu (mô hình khung thực thể)?

Vì vậy, về bản chất, tôi đang ánh xạ một mô hình dữ liệu vào mô hình miền, để sau đó nó có thể được ánh xạ trở lại mô hình dữ liệu. điều đó có nghĩa gì?

Ok hãy tưởng tượng bạn triển khai trang tạo tài khoản của mình ánh xạ bài đăng mẫu trực tiếp đến một đối tượng EF sau đó được lưu vào db.

Cho phép thêm rằng cơ sở dữ liệu có nhiều hạn chế khác nhau để ngăn chặn dữ liệu sai hoàn toàn được nhập vào. Tài khoản luôn có Khách hàng, v.v.

Mọi thứ dường như hoạt động tốt. Nhưng sau đó doanh nghiệp làm cho một quy tắc mới.

• Tài khoản được tạo vào thứ Năm nhận được lãi suất thưởng 2%. (giả sử lãi suất là một trong các trường tài khoản)

Bây giờ bạn phải đặt logic này ở đâu đó và bạn không có đối tượng miền để đặt nó vào.

DDD giả định rằng bạn sẽ luôn có những loại quy tắc này, và bạn có thể làm được. Tạo một tài khoản phải có nhiều kiểm tra khác nhau, nhật ký kiểm toán, v.v. nó sẽ không chỉ là 'viết một hàng vào db'

Lập kế hoạch tên miền của bạn với giả định rằng không có bộ điều khiển MVC hoặc bộ điều khiển MVC nào có logic bổ sung. Hãy đảm bảo bạn nắm bắt được tất cả các yêu cầu và tất cả chúng đều nằm trong mô hình miền.

điều đó có nghĩa gì?

Câu trả lời ngắn gọn: không .

Câu trả lời dài hơn: các mẫu nặng để phát triển mô hình miền không áp dụng cho các phần của giải pháp đó chỉ là cơ sở dữ liệu.

Udi Dahan đã có một quan sát thú vị có thể giúp làm rõ điều này

Dahan cho rằng một dịch vụ phải có cả chức năng và dữ liệu. Nếu nó không có dữ liệu, thì đó chỉ là một chức năng. Nếu tất cả những gì nó làm là thực hiện các thao tác CRUD trên dữ liệu, thì đó là cơ sở dữ liệu.

Quan điểm của mô hình miền, xét cho cùng, là đảm bảo rằng tất cả các cập nhật cho dữ liệu duy trì bất biến kinh doanh hiện tại. Hoặc, nói cách khác, mô hình miền chịu trách nhiệm đảm bảo rằng cơ sở dữ liệu hoạt động như hệ thống bản ghi là chính xác.

Khi bạn đang xử lý một hệ thống CRUD, bạn thường không phải là hệ thống ghi dữ liệu. Thế giới thực là cuốn sách kỷ lục và cơ sở dữ liệu của bạn chỉ là một đại diện được lưu trữ cục bộ của thế giới thực.

Chẳng hạn, hầu hết thông tin xuất hiện trong hồ sơ người dùng, như địa chỉ email hoặc số nhận dạng do chính phủ cấp, có nguồn sự thật nằm ngoài doanh nghiệp của bạn - đó là quản trị viên thư của người khác gán và thu hồi địa chỉ email, không phải ứng dụng của bạn. Chính phủ chỉ định SSN, không phải ứng dụng của bạn.

Vì vậy, thông thường bạn sẽ không thực hiện bất kỳ xác thực tên miền nào trên dữ liệu đến với bạn từ thế giới bên ngoài; bạn có thể kiểm tra tại chỗ để đảm bảo dữ liệu được hình thành tốt và được vệ sinh đúng cách ; nhưng đó không phải là dữ liệu của bạn - mô hình miền của bạn không có quyền phủ quyết.

Trong cách tiếp cận DDD bằng cách sử dụng các lớp, có vẻ như các hoạt động CRUD đi qua lớp miền. nhưng ít nhất trong trường hợp của chúng tôi, điều này dường như không có ý nghĩa.

Điều đó đúng cho trường hợp cơ sở dữ liệu là sổ ghi chép .

Ouarzy đặt nó theo cách này .

Mặc dù làm việc với rất nhiều mã kế thừa, tôi quan sát các lỗi phổ biến để xác định những gì bên trong miền và những gì bên ngoài.

Một ứng dụng có thể được coi là CRUD chỉ khi không có logic nghiệp vụ xung quanh mô hình dữ liệu. Ngay cả trong trường hợp (hiếm) này, mô hình dữ liệu của bạn không phải là mô hình miền của bạn. Điều đó chỉ có nghĩa là, vì không có logic kinh doanh nào được tham gia, chúng tôi không cần bất kỳ sự trừu tượng hóa nào để quản lý nó và do đó chúng tôi không có mô hình miền.

Chúng tôi sử dụng mô hình miền để quản lý dữ liệu thuộc về miền; dữ liệu từ bên ngoài miền đã được quản lý ở một nơi khác - chúng tôi chỉ lưu trữ một bản sao.

Greg Young sử dụng các hệ thống kho như một minh họa chính cho các giải pháp trong đó sổ ghi chép ở một nơi khác (ví dụ: sàn kho). Việc triển khai mà anh mô tả rất giống với cơ sở dữ liệu của bạn - một cơ sở dữ liệu logic để thu thập các thông điệp nhận được từ kho, và sau đó là một cơ sở dữ liệu logic riêng biệt lưu trữ các kết luận rút ra từ phân tích các thông báo đó.

Vì vậy, có lẽ chúng ta có hai bối cảnh giới hạn ở đây? Mỗi người có một mô hình khác nhau cho mộtinvestment account

Có lẽ. Tôi miễn cưỡng gắn thẻ nó như một bối cảnh bị ràng buộc, bởi vì không rõ hành lý khác đi kèm với nó là gì. Có thể là bạn có hai bối cảnh, đó có thể là một bối cảnh với sự khác biệt tinh tế trong ngôn ngữ phổ biến mà bạn chưa chọn.

Kiểm tra giấy quỳ có thể có: bạn cần bao nhiêu chuyên gia tên miền để bao quát phổ này hoặc chỉ một người nói về các thành phần theo những cách khác nhau. Về cơ bản, bạn có thể đoán được bạn có bao nhiêu bối cảnh bị ràng buộc bằng cách làm ngược luật của Conway.

Nếu bạn coi bối cảnh giới hạn được liên kết với các dịch vụ, có thể dễ dàng hơn: bạn có thể triển khai hai phần chức năng này một cách độc lập không? Có gợi ý hai bối cảnh giới hạn; nhưng nếu chúng cần được giữ đồng bộ, thì có lẽ nó chỉ là một.

Trong miền của bạn, bạn không cần phải biết rằng cơ sở dữ liệu thậm chí còn tồn tại.

Tên miền của bạn là về các quy tắc kinh doanh. Những thứ cần tồn tại khi công ty làm cho cơ sở dữ liệu của bạn bị phá sản. Đó là, nếu bạn muốn công ty của bạn tồn tại. Thật tuyệt khi những quy tắc đó không quan tâm rằng bạn đã thay đổi cách bạn duy trì dữ liệu.

Chi tiết cơ sở dữ liệu tồn tại và cần phải được xử lý. Họ nên sống ở một nơi khác. Đặt chúng qua một ranh giới. Kiểm soát cẩn thận cách bạn giao tiếp qua ranh giới đó hoặc đó không phải là ranh giới.

Chú Bob có điều này để nói về những gì cần đưa dữ liệu của bạn vào:

Thông thường dữ liệu vượt qua các ranh giới là các cấu trúc dữ liệu đơn giản. Bạn có thể sử dụng các cấu trúc cơ bản hoặc các đối tượng Truyền dữ liệu đơn giản nếu muốn. Hoặc dữ liệu có thể chỉ đơn giản là đối số trong các cuộc gọi chức năng. Hoặc bạn có thể đóng gói nó thành một hashmap hoặc xây dựng nó thành một đối tượng.

Điều quan trọng là các cấu trúc dữ liệu đơn giản, đơn độc được truyền qua các ranh giới. Chúng tôi không muốn gian lận và vượt qua các hàng Thực thể hoặc Cơ sở dữ liệu. Chúng tôi không muốn các cấu trúc dữ liệu có bất kỳ loại phụ thuộc nào vi phạm Quy tắc phụ thuộc.

[V]] khi chúng tôi chuyển dữ liệu qua một ranh giới, nó luôn ở dạng thuận tiện nhất cho vòng tròn bên trong.

Kiến trúc sạch

Ông cũng giải thích làm thế nào các lớp bên ngoài của bạn phải là bổ sung cho các lớp bên trong của bạn để các lớp bên trong thậm chí không biết các lớp bên ngoài tồn tại.

Làm theo cách tương tự và bạn sẽ có một vị trí đẹp để bỏ qua cơ sở dữ liệu nơi bạn có thể lo lắng về quy tắc xác thực đầu vào, quy tắc đầu vào phải được duy trì bằng cách nào đó, quy tắc để chạy tính toán, quy tắc để gửi kết quả đó đến bất kỳ đầu ra nào. Thật ra việc đọc loại mã này thực sự dễ dàng hơn.

Đó là hoặc bạn quyết định rằng tên miền của bạn thực sự chỉ để thao túng cơ sở dữ liệu. Trong trường hợp đó, ngôn ngữ miền của bạn là SQL. Nếu tốt như vậy nhưng đừng hy vọng việc bạn thực hiện các quy tắc kinh doanh sẽ tồn tại một sự thay đổi trong sự kiên trì. Cuối cùng bạn sẽ cần phải viết lại hoàn toàn chúng.

Áp dụng lý thuyết DDD:

Có hai bối cảnh bị ràng buộc trong miền đó:

• Các tính toán của tài khoản đầu tư. Mô hình toán học tài khoản đầu tư là một yếu tố có thể là Tổng hợp.
• Tài chính cốt lõi. Tài khoản đầu tư của khách hàng là một trong những Thực thể.

Mỗi Bối cảnh Bounded có thể có một thiết kế kiến ​​trúc khác nhau.

Thí dụ:

Tài khoản đầu tư của khách hàng là một Thực thể (có thể là Tổng hợp, tùy thuộc vào tên miền) và tính bền vững của dữ liệu được thực hiện thông qua Kho lưu trữ của thực thể (RDB hoặc loại DB khác như Cơ sở dữ liệu OO).

Không có cách tiếp cận DDD đối với các hoạt động CRUD. Để có một trường DB được gắn với dữ liệu của một đối tượng phá vỡ các nguyên tắc thiết kế.