Vùng chứa IoC và Thiết kế Điều khiển Tên miền

Question

Tôi đã tìm kiếm hướng dẫn về cách sử dụng vùng chứa IoC trong thiết kế định hướng miền. Cuốn sách của Evan không may không liên quan đến chủ đề này. Hướng dẫn duy nhất đáng kể tôi có thể tìm thấy trên internet là here.

Rất nhiều điểm của Malovic rất thông dụng nhưng tôi lo lắng về một vài trong số đó. Ông đề nghị rằng container IoC nên được dành riêng cho việc giải quyết các dịch vụ và việc sử dụng một container IoC để giải quyết các phụ thuộc miền là một ý tưởng tồi. Tuy nhiên, ông không sao lưu khẳng định này với bất kỳ ví dụ nào. Ông đơn giản tuyên bố nó như là một vấn đề của thực tế.

Sau đó, ông tiếp tục nói rằng việc trộn các thùng chứa IoC và các nhà máy không có ý nghĩa. Điều này dường như mâu thuẫn với điểm đầu tiên của anh ta. Nếu, trên thực tế, phụ thuộc miền không nên được giải quyết bởi một container IoC như thế nào sau đó họ nên được giải quyết? Cuốn sách của Evan chỉ rõ các nhà máy là sự lựa chọn hợp lý.

Tôi sẽ đánh giá cao mọi thông tin bạn có về vấn đề này. Tôi là một người mới khi nói đến cả DDD và IoC. Tôi đang đấu tranh để nắm bắt cách thức IoC và DDD có thể làm việc cùng nhau.

Answer 1

Theo ý kiến ​​của tôi, anh ấy đúng về việc không sử dụng vùng chứa IoC trong mô hình miền. Đó là thực tế tôi làm theo bản thân mình là tốt. Ý tưởng cơ bản là các dịch vụ có thể chứa các phụ thuộc cơ sở hạ tầng và do đó nó khôn ngoan để giả lập chúng. Các thực thể miền không có, vì vậy không quan trọng để giả lập chúng (vẫn viết mã cho giao diện là thực hành tốt).

Các nhà máy cho các thực thể miền không được trong vùng chứa IoC, nhưng các nhà máy cho dịch vụ nên. Về cơ bản bạn có thể tham khảo các nhà máy thực thể trong các dịch vụ của bạn. Nó không phải là khớp nối rất chặt chẽ.

Tốt đọc về IoC có thể được tìm thấy tại Billy McCafferty's blog post "Dependency Injection 101"

Answer 2

container IOC là vô giá khi thiết kế mã đơn vị-kiểm chứng và là trực giao với DDD. Bạn có thể tự mình tạo ra các mẫu nhà máy và nhà xây dựng nếu bạn muốn ... bởi vì tại sao phải trải qua những rắc rối?

Tuyệt đối. Sử dụng một thùng chứa IOC đủ mạnh để đáp ứng các yêu cầu cụ thể của bạn; không nhiều không ít.

Answer 3

Chúng tôi sử dụng DDD và tiêm phụ thuộc (mẫu), nhưng không sử dụng khung tiêm phụ thuộc.

Một vấn đề với khung tiêm phụ thuộc phổ biến là cách chúng tách cấu hình thành các tệp XML. XML là một ngôn ngữ đánh dấu tuyệt vời. Làm thế nào nó trở thành một ngôn ngữ cấu hình, tôi sẽ không bao giờ hiểu được. Vấn đề, tất nhiên, là bạn phải chạy các ứng dụng trước khi bạn biết nếu tất cả mọi thứ được dây lên một cách chính xác. Thật khó để xem mã nào được sử dụng ở đâu. Nếu bạn đang sử dụng các giao diện, thì tham chiếu duy nhất đến một triển khai sẽ nằm trong một tệp XML, đó là khó khăn hơn để phát hiện. Và cuối cùng bạn bị mất an toàn loại và generics. (Tôi từng thấy một lỗi khủng khiếp trong quá trình sản xuất đã bị trình biên dịch bắt giữ mà chúng tôi không sử dụng XML.)

Tôi nên chỉ ra rằng tôi không nói rằng việc tiêm phụ thuộc là xấu. Nó là một mô hình cơ bản của thiết kế đối tượng tốt. Nhưng hoàn toàn không có gì sai khi làm dây trong nhà máy.

Tại hai dự án cuối cùng của mình, chúng tôi đã xóa một lượng lớn "mã" ra khỏi tệp XML và vào các nhà máy. Các nhà máy được kết nối với các dịch vụ quản lý container (chẳng hạn như các kết nối JDBC, các kết nối JMS và vv). Ứng dụng đã trở nên đơn giản hơn nhiều để hiểu, bởi vì nhà máy ít tiết hơn XML. Và với tư cách là một lập trình viên Java, việc kết nối với nhau một chương trình bằng cách sử dụng không gian điều khiển, thay vì XML twiddling - và IDE của bạn sẽ nổi bật hơn khi bạn đã phá vỡ một thứ gì đó.

Trong thử nghiệm tích hợp, chỉ cần tạo các đối tượng như bạn làm trong nhà máy.

tức,

dbConnection = DatabaseConnectionFactory.connection();  
serviceUnderTest = new PaymentProcessor(new CustomerRepository(connection));