Thiết kế hướng miền có hữu ích / hiệu quả cho các miền không quá phức tạp không?

Khi đánh giá một dự án tiềm năng tại nơi làm việc, tôi đã gợi ý rằng có thể thuận lợi khi sử dụng phương pháp thiết kế hướng theo miền cho mô hình đối tượng của nó. Dự án không có một miền quá phức tạp, vì vậy đồng nghiệp của tôi đã ném nó vào tôi:

Người ta đã nói rằng DDD rất thuận lợi trong trường hợp có một mô hình miền phức tạp (thì ... Nó áp dụng bất cứ khi nào chúng ta đang hoạt động trong một miền phức tạp, phức tạp, Eric Eric Evans).

Điều tôi mất là - cách bạn xác định độ phức tạp của tên miền? Nó có thể được xác định bởi số lượng gốc tổng hợp trong mô hình miền không? Là sự phức tạp của một miền trong sự tương tác của các đối tượng?

Tên miền mà chúng tôi đang đánh giá có liên quan đến xuất bản và quản lý nội dung trực tuyến.

Sự phức tạp của logic kinh doanh, còn được gọi là hành vi ứng dụng, là yếu tố quan trọng nhất. Yếu tố quan trọng thứ hai là có bao nhiêu khoảng cách giữa vấn đề kỹ thuật và từ vựng kinh doanh được sử dụng để mô tả vấn đề đó, vì DDD là về việc tạo ra một từ vựng chung giữa doanh nghiệp và nhóm kỹ sư.

Một số mẫu được sử dụng trong DDD thường hữu ích trong kiến ​​trúc ứng dụng doanh nghiệp, chẳng hạn như mẫu Kho lưu trữ, Bối cảnh giới hạn và Kiến trúc phân lớp. Chỉ vì bạn đang sử dụng các mẫu đó, không có nghĩa là bạn đang thực hiện thiết kế theo miền.

Nếu không có nhiều hành vi, nghĩa là, bạn chủ yếu lưu trữ dữ liệu và không hành động trên dữ liệu đó, có thể có ít giá trị hơn trong việc xây dựng lớp miền đó. Trong quản lý nội dung, nếu tất cả những gì bạn làm là phê duyệt và xuất bản, có thể điều đó có thể được biểu thị bằng các cờ trong hệ thống, thay vì các phương thức miền. Nhưng khi bạn bắt đầu thêm hành vi bổ sung, sự phù hợp của lớp miền đầy đủ sẽ trở nên rõ ràng hơn.

Nếu chúng ta đang nói về quản lý nội dung, đây là một số quy tắc (tưởng tượng) có thể bắt đầu gợi ý về nhu cầu DDD:

• Nếu câu chuyện bị cấm vận cho đến ngày xx / yy / zz, hãy xuất bản để in, sau đó lên web; nếu không có lệnh cấm vận, hãy xuất bản lên web và sẵn sàng để in
• Làm cho câu chuyện này có sẵn phía sau paywall cho các thuê bao trả tiền ngay lập tức; phát hành ra công chúng 2 tuần sau
• Sau khi một câu chuyện được viết, hãy gửi nó cho một biên tập viên để sửa đổi, hiệu đính và phê duyệt. Khi được phê duyệt, gửi nó cho sản xuất. Nếu sản xuất cắt giảm câu chuyện vì lý do không gian, hãy tạo một phiên bản mở rộng có sẵn trực tuyến.