Có phải Inversion của Control Control thúc đẩy mô hình tên miền thiếu máu

Khi tôi sử dụng IoC Container trong dự án cuối cùng của mình, tôi đã kết thúc với các thực thể thiếu máu và hầu hết logic kinh doanh của tôi trong Dịch vụ phi trạng thái.

Tôi đã thấy các dự án được viết bởi các nhà phát triển khác sử dụng "Đảo ngược kiểm soát" và chúng luôn luôn là "Thiếu máu".

Vì "Mô hình miền thiếu máu" là mô hình chống, nên có thể sử dụng IoC và Rich Domain không? Có bất kỳ ví dụ tốt, dự án nguồn mở nào làm được điều đó không?

Dành cho người mới bắt đầu: DI và IoC không phải là từ đồng nghĩa. Tôi xin lỗi nhưng tôi phải chỉ ra điều đó (dường như với tôi rằng bạn nghĩ họ như vậy).

Đối với yêu cầu của bạn ... Chà, Dependency Injection chỉ là một công cụ. Làm thế nào bạn sẽ sử dụng công cụ này là điều hoàn toàn riêng biệt. Ngoài ra còn có các công cụ khác (mẫu thiết kế) có thể gây ra vấn đề. Ví dụ, tôi cảm thấy rằng việc áp dụng rộng rãi mẫu MVC là một trong những thành phần quan trọng để hình thành mô hình chống mô hình miền thiếu máu: Bộ điều khiển (trong các ứng dụng đơn giản hơn, trong các ứng dụng phức tạp hơn sẽ là Lớp dịch vụ bổ sung) chịu trách nhiệm xác thực các quy tắc kinh doanh , thực thi chúng cũng như chuyển đổi các thực thể DB thành một cái gì đó hữu ích, trong khi Lớp nghiệp vụ biến thành Lớp truy cập dữ liệu đơn giản là ORM đơn giản với ánh xạ một-một đến các thực thể cơ sở dữ liệu.

Chắc chắn đó là cách bạn thiết kế ứng dụng của mình - bạn có thể tạo Mô hình miền chính xác nếu bạn muốn và tất cả các IoC, DI, MVC này không ngăn bạn. Điều có thể ngăn bạn là đội của bạn. Bạn bằng cách nào đó cần phải thuyết phục họ sử dụng đúng đường dẫn và có thể khó vì nhiều Nhà phát triển phần mềm không có nền tảng kiến ​​trúc mạnh mẽ.

Hầu hết (nếu không phải tất cả) các ứng dụng là sự pha trộn giữa các mối quan tâm về cơ sở hạ tầng và tên miền. Khi bạn đạt đến một mức độ phức tạp nhất định, bạn sẽ dễ dàng quản lý hơn nếu tên miền được tách ra khỏi cơ sở hạ tầng để dễ lý luận hơn và có thể phát triển độc lập.

Tất nhiên, mô hình miền vẫn cần liên lạc với phần còn lại của hệ thống và thông thường, điều này sẽ là với các dịch vụ không trạng thái (là một phần của miền) có mối quan tâm về cơ sở hạ tầng (như quyền truy cập cơ sở dữ liệu) được đưa vào chúng. Sử dụng bộ chứa IoC không loại bỏ sự phụ thuộc này, nó di chuyển cấu hình của nó sang một khu vực riêng - một lần nữa giúp dễ dàng lý luận và duy trì.

Các thực thể đang lưu trữ nhà nước và phải chịu trách nhiệm cho các quy tắc kinh doanh. Nếu các dịch vụ của bạn đang thực thi tất cả các bất biến và các quy tắc kinh doanh khác thì có khả năng logic đó đã sai.

Bây giờ nếu bạn đã có logic ở đúng nơi mà vẫn kết thúc với các dịch vụ không hơn bao bọc xung quanh các cơ sở hạ tầng và các thực thể chỉ là túi tài sản thì rất có thể miền không đủ phức tạp để biện minh chi phí hoạt động của mô hình riêng. Bất cứ điều gì bạn sẽ đọc về DDD sẽ có từ chối trách nhiệm rằng nó thực sự chỉ dành cho các tên miền phức tạp, nhưng điều này dường như quá thường xuyên bị lãng quên.

Về nguồn. Bắt đầu với tác phẩm của Fowler trên Mô hình miền thiếu máu . Ông tham khảo Thiết kế hướng miền của Eric Evan như một ví dụ về thực hành tốt. Mã nguồn cho điều đó là ở đây . Tải về nó.

Quan sát rằng nó sử dụng Inversion of Control (tìm kiếm @Autowired) và có các lớp dịch vụ (TicketService) và các lớp "quy trình kinh doanh" (ví dụ: ItineraryUpdater).

Bài viết gốc của Fowler bắt đầu con đường dẫn đến ví dụ mà bạn đang tìm kiếm.

có thể sử dụng IoC và Rich Domain không? Có bất kỳ ví dụ tốt, dự án nguồn mở nào làm được điều đó không?

Tôi giả sử bạn có nghĩa là DI thay vì IoC và dự án bạn đã làm việc sử dụng container DI như Spring. IoC có hai hương vị chính: mẫu DI và Locator. Tôi không thấy lý do tại sao mô hình Định vị phải là một vấn đề, vì vậy hãy tập trung vào DI.

Tôi không nghĩ rằng nó có thể, hoặc ít nhất sẽ rất không chính xác. Khía cạnh chính của các thùng chứa DI là chúng kiểm soát việc tạo ra các đối tượng khi chúng tiêm chúng vào các vật thể khác ("các đối tượng được quản lý"). Tập hợp các đối tượng được quản lý còn sống khi các dự án chạy độc lập với các mục miền tồn tại trong dự án của bạn nhưng phụ thuộc vào cách các đối tượng được nối dây và phạm vi nào (singleton, nguyên mẫu) được gán cho chúng.

Đây là lý do tại sao bạn không muốn để bộ chứa DI quản lý các đối tượng miền của mình. Nhưng nếu bạn tạo các đối tượng theo cách thủ công (với mới), bạn không thể đưa các đối tượng khác vào đối tượng miền của mình. . Do đó, bạn sẽ không muốn đặt chức năng vào các đối tượng miền hoặc bạn sẽ mất các tính năng của DI.

Tôi không thấy làm thế nào một container DI giả định có thể hoạt động mà không quản lý các đối tượng của bạn và không có triển khai nào hiện có cho phép điều đó. Vì vậy, thật công bằng khi tuyên bố rằng DI dựa vào việc quản lý các đối tượng. Do đó, nó sẽ luôn cám dỗ bạn chia các đối tượng Rich Domain tiềm năng thành một lớp thiếu máu và một hoặc một vài lớp tập lệnh giao dịch.