Cài đặt cấp ứng dụng trong DDD?

Question

Chỉ muốn có được những suy nghĩ của nhóm về cách xử lý các chi tiết cấu hình của các thực thể.

Điều tôi đang nghĩ đến cụ thể là cài đặt cấp cao có thể được quản trị viên thay đổi. loại thứ mà bạn có thể lưu trữ trong ứng dụng hoặc web.config cuối cùng, nhưng từ góc nhìn DDD nên được đặt ở đâu đó trong các đối tượng một cách rõ ràng.

Vì lợi ích của đối số, hãy xem ví dụ về ứng dụng blog hoặc blog dựa trên web.

Một thực thể Blog Entry cho có bất kỳ số lượng các thiết lập ví dụ như tác giả, nội dung, vv

Nhưng bạn cũng có thể muốn đặt (ví dụ) Mô tả hoặc từ khóa mà tất cả các mục trong trang web nên bắt đầu với mặc định nếu chúng không bị tác giả thay đổi. Chắc chắn, bạn chỉ có thể tạo các hằng số đó trong lớp, nhưng sau đó chủ sở hữu trang web không thể thay đổi các giá trị mặc định.

Vì vậy, suy nghĩ của tôi như sau:

1) sử dụng lớp cấp (tĩnh) tính chất đại diện cho những thiết lập, và sau đó đặt chúng khi ứng dụng khởi động, hoặc thiết lập chúng từ DB hoặc từ web .config.

hoặc

2) sử dụng một thực thể riêng biệt để giữ các thiết lập, có thể là một cuốn từ điển, hoặc sử dụng nó trực tiếp hoặc có nó là một thành viên của lớp nhập

gì tấn công tất cả các bạn là dễ dàng nhất/Linh hoạt? Mối quan tâm của tôi là điều đầu tiên là nó không tấn công tôi như rất có thể cắm được (nếu tôi muốn thêm nhiều tính năng hơn) vì việc thay đổi các phương thức lớp của thực thể sẽ làm cho tôi thay đổi chính ứng dụng đó.). Điều thứ hai cảm thấy như nó nặng hơn, mặc dù, đặc biệt là nếu tôi sau đó phải đúc hoặc phân tích các giá trị ra khỏi một từ điển.

Answer 1

Tôi sẽ nói rằng liệu giá trị có thể định cấu hình hay không là không liên quan từ quan điểm của Mô hình miền - điều quan trọng là được định nghĩa bên ngoài.

Giả sử bạn có một lớp học phải có Tên. Nếu Tên luôn được yêu cầu, nó phải được đóng gói như là một bất biến không phụ thuộc vào nguồn của giá trị. Dưới đây là ví dụ C#:

public class MyClass 
{ 
    private string name; 

    public MyClass(string name) 
    { 
     if(name == null) 
     { 
      throw new ArgumentNullException("name"); 
     } 

     this.name = name; 
    } 

    public string Name 
    { 
     get { return this.name; } 
     set 
     { 
      if(value == null) 
      { 
       throw new ArgumentNullException("name"); 
      } 
      this.name = value; 
     } 
    } 
} 

Lớp học như thế này bảo vệ hiệu quả bất biến: Tên không được rỗng. Mô hình miền phải gói gọn các biến thể như thế này mà không quan tâm đến người tiêu dùng nào sẽ sử dụng chúng - nếu không, chúng sẽ không đáp ứng được mục tiêu của Supple Design.

Nhưng bạn đã hỏi về giá trị mặc định. Nếu bạn có một giá trị mặc định tốt cho Tên, thì làm thế nào để bạn giao tiếp giá trị mặc định đó cho MyClass.

Đây là nơi các Nhà máy có ích. Bạn chỉ cần tách riêng việc xây dựng các đối tượng của bạn khỏi việc triển khai chúng. Đây thường là một ý tưởng hay trong mọi trường hợp. Cho dù bạn chọn triển khai Trình xây dựng Nhà máy hoặc Trình xây dựng Trừu tượng thì ít quan trọng hơn, nhưng Nhà máy Trừu tượng là lựa chọn mặc định tốt.

Trong trường hợp của MyClass, chúng ta có thể xác định các giao diện IMyClassFactory:

public interface IMyClassFactory 
{ 
    MyClass Create(); 
} 

Bây giờ bạn có thể định nghĩa một thực hiện mà kéo tên từ một tập tin cấu hình:

public ConfigurationBasedMyClassFactory : IMyClassFactory 
{ 
    public MyClass Create() 
    { 
     var name = ConfigurationManager.AppSettings["MyName"]; 
     return new MyClass(name); 
    } 
} 

Hãy chắc chắn rằng mã cần các cá thể của MyClass sử dụng IMyClassFactory để tạo nó thay vì new'ing nó theo cách thủ công.