DDD với ORM logic kinh doanh nên đi đâu?

Tôi đã sử dụng một công cụ MDA (kiến trúc hướng mô hình) trong quá khứ nơi chúng tôi mô hình hóa thông qua UML và điều này tạo ra các thực thể kinh doanh (mô hình miền của chúng tôi) và ORM (ánh xạ, v.v.) trong số những thứ khác.

Rất nhiều mã doanh nghiệp và dịch vụ hoạt động trên miền là một phần của mô hình và kho lưu trữ của chúng tôi đã trả lại các thực thể kinh doanh (vì vậy không thể chuyển sang ORM khác (không phải chúng tôi muốn)).

Tuy nhiên, bây giờ tôi đang bắt đầu một dự án và tôi muốn nghĩ về DDD.

Cho đến giờ tôi cảm thấy như thể đưa logic kinh doanh của mình vào mô hình miền của mình và thông qua các kho lưu trữ, tôi sẽ làm việc với ORM (mà tôi đã chọn). Tuy nhiên, nếu tôi muốn tiếp tục sử dụng công cụ MDA cho phần ORM của ứng dụng, mô hình được tạo ở đây sẽ rất thiếu máu (tức là không chứa bất kỳ logic nghiệp vụ nào). Tương tự nếu tôi sử dụng khung Entity (.net) hoặc NHibernate cho ORM của mình thì đó cũng là một mô hình thiếu máu.? Tôi không chắc chắn nơi bạn sẽ đặt logic kinh doanh nếu tôi chỉ sử dụng NHibernate.

Tôi có đúng không khi nghĩ theo cách này, nói cách khác với DDD tất cả logic kinh doanh trong miền và chỉ sử dụng ORM để duy trì thông qua các kho lưu trữ?

vì vậy không thể chuyển sang ORM khác (không phải chúng tôi muốn)).

Điều đó có vẻ sai. Một lợi thế lớn của mẫu kho lưu trữ là bạn ẩn logic truy cập dữ liệu và nó có thể dễ dàng trao đổi.

Cho đến giờ tôi cảm thấy như thể đưa logic kinh doanh của mình vào mô hình miền của mình và thông qua các kho lưu trữ, tôi sẽ làm việc với ORM (mà tôi đã chọn). Tuy nhiên, nếu tôi muốn tiếp tục sử dụng công cụ MDA cho phần ORM của ứng dụng, mô hình được tạo ở đây sẽ rất thiếu máu (tức là không chứa bất kỳ logic nghiệp vụ nào). Tương tự nếu tôi sử dụng khung Entity (.net) hoặc NHibernate cho ORM của mình thì đó cũng là một mô hình thiếu máu.? Tôi không chắc chắn nơi bạn sẽ đặt logic kinh doanh nếu tôi chỉ sử dụng NHibernate.

Một mô hình miền thiếu máu được coi là một thực tiễn xấu của nhiều người, ví dụ như Martin Fowler. Bạn nên tránh một thiết kế như vậy bởi vì một mô hình như vậy dẫn đến các kỹ thuật thiết kế theo thủ tục hơn là một thiết kế hướng đối tượng tốt. Sau đó, bạn có các lớp dữ liệu và các lớp quản lý / xử lý có nghĩa là bạn tách biệt trạng thái và hành vi. Nhưng một đối tượng thực sự nên là "trạng thái và hành vi".

NHibernate làm một công việc tuyệt vời ở sự thiếu hiểu biết dai dẳng. Bạn có thể ẩn đi các chi tiết ánh xạ trong XML hoặc với FluentNHibernate và chỉ cần viết các POCO đơn giản. Thật dễ dàng để tạo một mô hình miền phong phú với NHibernate. Tôi nghĩ bạn cũng có thể làm điều đó với khung thực thể và công cụ MDA. Miễn là công cụ này tạo ra các lớp một phần, bạn có thể mở rộng mã được tạo ra khá dễ dàng mà không phải lo lắng rằng một thế hệ mới có thể phá hủy mã do người dùng viết của bạn.

Để cắt ngắn câu chuyện dài này. Khi bạn sử dụng NHibernate, không có gì, tôi không lặp lại điều gì , ngăn bạn nắm lấy một mô hình miền phong phú. Tôi khuyên bạn nên sử dụng nó với FluentNHibernate và lập bản đồ bằng tay. Mã bản đồ chỉ mất 5 đến 10 phút để viết. Tôi cho rằng điều tương tự cũng đúng với khung thực thể và các công cụ của nó ít nhất tạo ra các lớp một phần có thể dễ dàng mở rộng.

Tôi có đúng không khi nghĩ theo cách này, nói cách khác với DDD tất cả logic kinh doanh trong miền và chỉ sử dụng ORM để duy trì thông qua các kho lưu trữ?

Đối với hầu hết các phần bạn là chính xác. Bạn nên có một mô hình miền phong phú. Đặc biệt là khi mọi thứ trở nên ngày càng phức tạp, việc bảo trì và mở rộng sẽ dễ dàng hơn khi bạn thiết kế đúng cách. Nhưng hãy nhớ rằng DDD cũng biết Dịch vụ (Lớp miền và Lớp ứng dụng) để triển khai logic kinh doanh và các nhà máy để đóng gói logic sáng tạo.

Tôi cũng có xu hướng phân biệt logic kinh doanh thành logic miền và logic kinh doanh ứng dụng thực tế. Logic miền là cách miền tương tác và hoạt động trong khi logic ứng dụng, là một lớp hoàn toàn khác, gói gọn cách thức miền được sử dụng cho trường hợp sử dụng / ứng dụng cụ thể. Thường thì tôi phải cập nhật mô hình miền để hỗ trợ các trường hợp sử dụng cụ thể và để làm cho nó mạnh hơn.

Tuy nhiên, nếu tôi muốn tiếp tục sử dụng công cụ MDA cho phần ORM của ứng dụng, mô hình được tạo ở đây sẽ rất thiếu máu (tức là không chứa bất kỳ logic nghiệp vụ nào).

Tôi không biết công cụ MDA nào bạn đang sử dụng, nhưng những công cụ tôi đã làm việc luôn tạo các lớp một phần để bạn có thể hoàn thành chúng với logic kinh doanh nhiều như bạn muốn.

Tuy nhiên, tôi cảm thấy các công cụ MDA ít phù hợp hơn một chút trong bối cảnh DDD so với ORM, bởi vì việc tạo mã thường có xu hướng tạo ra các lớp bị nhiễu với tiếng ồn cụ thể của công cụ thay vì các thực thể miền được biểu thị rõ ràng, được sắp xếp rõ ràng mà chúng ta mong đợi. Trên thực tế, những gì bạn thường nhận được là sự pha trộn của dữ liệu miền, logic kiên trì, logic xác thực ràng buộc ... và tôi không biết liệu có cách nào để tách những mối quan tâm này với hầu hết các công cụ MDA hay không.

Và tất nhiên, bạn không thể chạm vào mã được tạo ngoại trừ thông qua các lớp một phần, điều đó có nghĩa là bạn không thể loại bỏ hành vi chống DDD tiềm năng sẽ được tích hợp. Đây là vấn đề trong cách tiếp cận mà bạn muốn thực thi các rào cản nghiêm ngặt giữa các Tập hợp và điều chỉnh mối quan hệ giữa các thực thể của bạn một cách hoàn hảo. Xây dựng thời gian trong một môi trường tích hợp liên tục cũng có thể bị ảnh hưởng bởi bước tạo mã bổ sung.

Ngoài ra, tôi nghĩ Falcon đã nói rất nhiều về tất cả - hoàn toàn không có gì trong các công cụ ORM hoặc MDA ngăn bạn có các thực thể miền phong phú.

Những gì tôi làm trong nhóm của mình là mô hình hóa đối tượng, tên miền và thêm logic kinh doanh của tôi cùng một lúc. Tôi không sử dụng Mô hình phát triển hướng sẽ tạo mã từ mô hình nhưng thích cách tiếp cận chú thích. Ý tôi là ở cấp đối tượng bên trong sơ đồ lớp tôi thêm các bản mẫu ORM. Điều này sẽ thêm các chú thích liên tục trực tiếp vào mã tương thích với EJB3 / hibernate. Việc tạo cơ sở dữ liệu được thực hiện bởi Hibernate và chắc chắn không phải bởi các mẫu UML. Điều này tốt hơn rất nhiều vì nếu mã thay đổi và các chú thích được thêm vào không chính xác là những gì chuyên gia ngủ đông thì anh ấy / cô ấy có thể thay đổi nhưng mô hình vẫn tốt. Tôi cũng có thể thay đổi yêu cầu của mình và mô hình miền của tôi vẫn ổn.

Các nhà phát triển có thể thêm logic kinh doanh bên trong mỗi phương thức và thêm một nhận xét, tôi cũng có thể mô hình hóa và thêm các ràng buộc. Ví dụ: doanh số phải trên 50 nghìn nếu không vv .... Tôi không cần mã hóa mà chỉ cần viết trong mô hình và thông tin này sẽ được hiển thị cho nhóm nhà phát triển. UML thực sự mát mẻ và linh hoạt.