Mô hình miền thiếu máu và tiêm dịch vụ miền

Các mô hình miền thiếu máu được mô tả như một chất chống pattern trong thiết kế miền do Martin Fowler. Để có logic nghiệp vụ trên các mô hình miền, các dịch vụ miền thường được sử dụng. Nhưng việc tiêm các dịch vụ miền vào các mô hình miền được coi là có hại bởi Vaughn Vernon (xem "Thực hiện thiết kế hướng tên miền, Trang 387).

Theo tôi những ý kiến ​​đó là mâu thuẫn, điều này có đúng không? Làm thế nào cả hai điểm có thể được xem xét?

Đây có phải là mô hình miền thực sự phong phú với các dịch vụ miền được tiêm so với mô hình miền thiếu máu và các dịch vụ miền bình thường không?

Một mô hình thiếu máu chỉ đơn giản là một thùng chứa dữ liệu. Nó không chứa hành vi. (Điều này thực sự có thể được coi là một điều tốt trong mô hình chức năng.) Ngược lại với một mô hình thiếu máu không phải là một mô hình được tiêm đầy đủ các dịch vụ miền. Bạn đang mô tả hai thái cực - cả hai đều xấu.

Nếu bạn có một mô hình thiếu máu, bạn không hoàn toàn chấp nhận những gì OOP cung cấp. Nếu bạn bắt đầu tiêm dịch vụ vào các mô hình đó, có khả năng bạn đang tiêm những lo ngại không thuộc về nơi đó. Hoặc là hoặc mô hình của bạn thiếu máu hơn bạn nghĩ. Tại sao bạn lại cần dịch vụ khác ngoài việc cung cấp thứ gì đó bắt buộc nhưng thiếu? (Thiếu có thể có nghĩa là thiếu máu.)

Tránh cả hai "kể" dẫn đến thiết kế mạnh mẽ hơn. Bạn có một cái gì đó trong một dịch vụ mà một người mẫu cần? Có lẽ nó nên được chuyển đến mô hình. Nếu không, có lẽ bạn nên xem xét lại mối quan tâm của bạn. Hành vi của một mô hình nên hoạt động bên trong mô hình. Nó nên chủ yếu (nếu không chỉ) quan tâm đến chính nó với các thành viên. Nhưng hãy nhớ rằng, sẽ vẫn có những điều mà công việc trên hoặc với mô hình. Ví dụ: các mô hình không nên mở kết nối TCP hoặc lắng nghe các sự kiện UI, ngay cả khi chúng có liên quan. Đó là trách nhiệm của người khác và rằng ai đó không bao giờ thuộc về bên trong mô hình.

Nó không mâu thuẫn. Cả hai người đề xuất đều muốn bạn đặt mã thực tế của mình vào chính đối tượng miền.

I E.

public class Order
{
    private string status = "not bought";
    public void Buy()
    {
        this.status = "bought";
    }
}

đấu với ADM

public class Order
{
    public string Status = "not bought";
}

public class BuyingService
{
    public Order Buy(Order order)
    {
         Order o = new Order();
         o.status = "bought";
         return o;
    }
}

vs dịch vụ tiêm

public class Order
{
    public Order(IBuyingService bs)
    {
        _bs = bs;
    }
    private IbuyingService _bs;
    private string status = "not bought";
    public void Buy()
    {
        this.status = _bs.Buy();
    }
}

public class BuyingService : IBuyingService
{
    public string Buy()
    {
         return = "bought";
    }
}

Thẳng thắn mặc dù mỗi cách tiếp cận có điểm cộng và nhược điểm. Người bạn chọn phần lớn là vấn đề sở thích cá nhân