6

Trong lớp miền thiết kế được điều khiển miền được cho là không có sự phụ thuộc với các lớp khác. tức là giao diện Kho lưu trữ có lớp miền trong khi triển khai ở lớp cơ sở hạ tầng.Lớp trong thiết kế điều khiển miền

Tuy nhiên, ngữ cảnh bị giới hạn (với tên miền + infra) được triển khai dưới dạng một đơn vị/có thể triển khai. Và các lớp thực sự là LOGICAL và không PHYSICAL. Vậy thì lợi thế thực sự của việc vẽ phân tách lớp ảo này giữa miền và cơ sở hạ tầng là gì?

Cập nhật

Trong lớp cách tiếp cận miền (dịch vụ) truyền thống được cho là phụ thuộc vào sở hạ tầng lớp. Tuy nhiên, khi nói đến DDD/clean/hexagonal architectures domain thì độc lập với các lớp khác. Tuy nhiên sự kiện với cách tiếp cận sạch/lục giác vẫn là lớp miền có một giao diện được thực hiện bởi lớp infra.

Vì vậy cho dù bạn sử dụng phương pháp tiếp cận lớp DDD/lục giác hoặc truyền thống, bạn vẫn phải giả lập kho lưu trữ và v.v. tức là miền không thực sự độc lập. Ý kiến ​​của bạn là gì?

Trả lời

6

Giả định đằng sau Domain Model pattern là Domain Model là một trong hai phần phức tạp nhất của ứng dụng, hoặc phần mà thay đổi thường xuyên hơn các bộ phận khác.

Mẫu mô hình miền cố gắng giải quyết mối quan tâm này bằng cách làm cho Mô hình miền độc lập với các mối quan tâm khác. Một trong những ưu điểm của việc này là bạn có thể kiểm tra đơn vị Mô hình miền trong sự cô lập các phụ thuộc của nó. Bạn cũng có thể thay đổi mô hình miền mà không phải thay đổi các phần khác của ứng dụng.

Đó là những lợi thế chính, nhưng cũng có nhược điểm. Việc tách có thể làm cho cơ sở mã khó điều hướng hơn và cũng có xu hướng đòi hỏi nhiều ánh xạ giữa các lớp. Có hay không this is worthwhile tùy thuộc vào các trường hợp cụ thể (mô hình miền phức tạp như thế nào, bạn có các lựa chọn thay thế xác minh nào khác, v.v.)

+0

Tôi đã cập nhật câu hỏi của mình, bạn có thể vui lòng kiểm tra lại không? –

+1

@FahimFarook Khi bạn tự viết, Mô hình miền độc lập về mặt logic, nhưng không độc lập về thể chất. –

+0

Cảm ơn @MarkSeemann Vì vậy, chúng ta có thể nói ngay cả trong lĩnh vực kinh doanh phương pháp tiếp cận lớp truyền thống là độc lập - cung cấp IoC là tại chỗ? Theo [link] (https://hendryluk.wordpress.com/2009/08/17/software-development-fundamentals-part-2-layered-architecture/) những gì tôi hiểu là các sơ đồ lớp N truyền thống chỉ là không chính xác/lừa đảo –

6

Trình điều khiển lớn nhất là cho phép các lớp khác nhau thay đổi mà không ảnh hưởng lẫn nhau. Ví dụ, tôi thường kiểm tra lớp miền của mình độc lập với lớp cơ sở hạ tầng của mình. Tôi làm điều này bằng cách chế nhạo DAO và kho lưu trữ của tôi, điều này cho phép các thử nghiệm của tôi chạy nhanh hơn nhiều, và làm cho chúng kém giòn hơn.

Tôi cũng đã sử dụng nó khi kho lưu trữ của tôi kết thúc cần triển khai mới (Oracle vs MS SQL vs Web Service). Nó giảm thiểu sự phức tạp của bạn khi bạn không phải viết lại toàn bộ ứng dụng của mình khi một dịch vụ back-end thay đổi từ bên dưới bạn.

Cuối cùng, việc chia nhỏ này có xu hướng giúp bạn hoàn thành SRP. Việc tích hợp lớp cơ sở dữ liệu của bạn vào lớp miền của bạn có xu hướng cho phép bạn bỏ qua điều này (ít nhất là theo kinh nghiệm của tôi). Nó không ép buộc bạn, nhưng nó chắc chắn khuyến khích hành vi xấu.

Đó là lý do tương tự chúng tôi không viết logic miền của mình trong giao diện người dùng của chúng tôi. Đối với bất kỳ ví dụ đủ nhỏ, đó là một sự lãng phí thời gian. Giá trị của nó chỉ trở nên rõ ràng khi bạn có một ứng dụng lớn, phức tạp.

Các vấn đề liên quan