Tái cấu trúc trong thiết kế hướng miền [đóng]

Tôi mới bắt đầu làm việc với một dự án và chúng tôi đang sử dụng thiết kế hướng tên miền (theo định nghĩa của Eric Evans trong Thiết kế hướng tên miền: Xử lý sự phức tạp trong trái tim của phần mềm . Tôi tin rằng dự án của chúng tôi chắc chắn là một ứng cử viên cho thiết kế này mô hình như Evans mô tả nó trong cuốn sách của mình.

Tôi đang vật lộn với ý tưởng liên tục tái cấu trúc.

Tôi biết tái cấu trúc là một điều cần thiết trong bất kỳ dự án nào và sẽ xảy ra chắc chắn khi phần mềm thay đổi. Tuy nhiên, theo kinh nghiệm của tôi, tái cấu trúc xảy ra khi nhu cầu của nhóm phát triển thay đổi, không phải là sự hiểu biết về miền thay đổi ("tái cấu trúc để có cái nhìn sâu sắc hơn" như Evans gọi nó). Tôi quan tâm nhất đến những đột phá trong việc hiểu mô hình miền. Tôi hiểu thực hiện các thay đổi nhỏ, nhưng nếu một thay đổi lớn trong mô hình là cần thiết thì sao?

Cách hiệu quả để thuyết phục bản thân (và những người khác) bạn nên tái cấu trúc sau khi bạn có được một mô hình miền rõ ràng hơn? Xét cho cùng, việc tái cấu trúc để cải thiện tổ chức hoặc hiệu suất mã có thể tách biệt hoàn toàn với cách biểu cảm theo mã ngôn ngữ phổ biến. Đôi khi dường như không có đủ thời gian để cấu trúc lại.

May mắn thay, SCRUM cho vay tự tái cấu trúc. Bản chất lặp của SCRUM giúp dễ dàng xây dựng một mảnh nhỏ và thay đổi và nó. Nhưng theo thời gian, mảnh đó sẽ lớn hơn và nếu bạn có một bước đột phá sau khi mảnh đó quá lớn thì sẽ quá khó để thay đổi?

Có ai từng làm việc trong một dự án sử dụng thiết kế hướng tên miền? Nếu vậy, sẽ thật tuyệt khi có được cái nhìn sâu sắc về cái này. Tôi đặc biệt muốn nghe một số câu chuyện thành công, vì DDD dường như rất khó để có được đúng.

Cảm ơn!

Tôi đã là một fan hâm mộ lớn của DDD trong một thời gian (có và không có mạng lưới an toàn của khung kiểm tra).

Toàn bộ khái niệm và vòng đời tái cấu trúc không thay đổi bởi vì bạn hiện đang sử dụng một phương pháp thiết kế mới. Nếu nó sẽ mất thời gian đáng kể, nó phải có lợi ích tỷ lệ thuận với dự án để có được thời gian đó từ ban quản lý.

Đối với việc thực hiện nó: trong một trường hợp, tôi đã tham gia vào một cuộc tái cấu trúc lớn trong 3 tháng vì một 'bước đột phá' trong cách hiểu về mô hình miền. Nó yêu cầu kiểm tra để xác minh hành vi hiện tại, kiểm tra để xác minh hành vi dự kiến ​​và thay đổi mã gọi. Tuy nhiên, lợi ích rất đáng kể và cho phép doanh nghiệp thực hiện nhiều việc cần làm trước đây nhưng không thể thực hiện được. Về bản chất, tái cấu trúc về cơ bản là một "tính năng".

Tái cấu trúc trong Thiết kế hướng miền là tôi nghĩ được điều khiển từ một nhu cầu, không phải là một cấu trúc lại "tốt đẹp". Ngay khi bạn xác định Mô hình miền không chính xác, mã / hệ thống không đại diện cho vấn đề trong thế giới thực.

Trường hợp cụ thể, gần đây chúng tôi đã làm việc trên một ứng dụng có độ phức tạp miền hợp lý. Đó là hệ thống Thanh toán / Hợp đồng và chúng tôi đã giới thiệu một loại tỷ lệ mới. Chúng tôi đã sử dụng một quy trình nhanh, chính xác là 2 tuần.

Ban đầu, chúng tôi xác định trong mô hình 2 tỷ lệ hoàn toàn tách biệt và không có mối quan hệ nào ngoại trừ thông qua Hợp đồng. Tuy nhiên, khi chúng tôi hoàn thành nhiều câu chuyện hơn, chúng tôi nhận ra rằng chúng thực sự giống nhau, đặc biệt là khi chúng tôi bắt đầu bọc tỷ lệ mới như một cái cũ chỉ để làm cho nó hoạt động. Đây là dấu hiệu cảnh báo đầu tiên.

Để cắt ngắn câu chuyện, chúng tôi có thể lấy 90% câu chuyện được thực hiện với mô hình không chính xác, nhưng chúng tôi đã đi đến điểm mà trong mỗi phần của mã chúng tôi đều gói Tỷ lệ mới như một câu chuyện cũ và / hoặc tạo nếu newRate khác oldRate MERYI ở đâu. Chúng tôi đã đập đầu vào bức tường thành ngữ. Chúng tôi đã đi được nửa chặng đường của dự án này và biết rằng thời gian hoàn thành sẽ theo cấp số nhân hoặc không thể thực hiện được với mô hình miền không chính xác. Vì vậy, chúng tôi cắn viên đạn, chia một câu chuyện thành tám câu chuyện khác và tái cấu trúc Mô hình miền.

Khi chúng tôi hoàn thành dự án, chúng tôi biết từ nhận thức đó là điều đúng đắn và là điều DUY NHẤT phải làm để thực hiện đúng.

Có mất thời gian không? Có, nhưng nếu chúng tôi không làm điều đó, nó sẽ mất nhiều thời gian hơn. Có phải DDD đã được thực hiện đúng không? Chà, thật vui là chúng tôi không biết về DDD vào thời điểm đó, nhưng ngay sau khi chúng tôi tham dự một hội thảo về DDD của Eric Evans, và tất cả tôi và các đồng nghiệp của tôi có thể làm là gật đầu. Tôi nghĩ rằng nếu chúng tôi biết DDD, chúng tôi sẽ chọn công cụ tái cấu trúc sớm hơn nhiều để tiết kiệm thời gian hơn.

Nếu bạn gặp lỗi gì đó trong Mô hình miền, điều quan trọng là phải sửa nó. Theo kinh nghiệm của tôi, chúng tôi đã bỏ lỡ một chút về cách mô hình miền kết nối với các thực thể khác nhau khi chúng tôi triển khai một số mô hình đó.

Điều này dẫn đến kết quả là mọi người thường sử dụng mô hình theo cách mà nó không được đặt ra và do đó phá vỡ các phần khác của mô hình để cố gắng "làm cho nó hoạt động".

Ngay khi bạn nhận ra rằng có một cái gì đó sai trong mô hình miền, hãy thay đổi nó càng nhanh càng tốt. Càng mất nhiều thời gian trước khi bạn tái cấu trúc nó, nó sẽ càng khó thay đổi đối với người dùng, các mô hình tinh thần hiện đã được điều chỉnh.

Đối với một số phần của mã, tái cấu trúc liên tục là quá mức cần thiết. Đối với một số phần khác của mã (trong DDD, cái gọi là Miền lõi ) là một điều cần thiết. Hiểu rằng mã không phải là cách đặt thêm tải nhận thức cho nhà phát triển (sự khác biệt giữa hiểu biết của chúng tôi về miền và việc triển khai hiện tại) sẽ khiến cho việc phát triển thêm trở nên khó khăn và / hoặc tốn kém hơn.

Câu hỏi là: "những tiến hóa này có cần thiết không?". Trong Miền chính (lĩnh vực tạo ra sự khác biệt trong kinh doanh), câu trả lời là "Có!". Bởi vì đó là thuốc của miền mà doanh nghiệp quan tâm hơn và là thứ sẽ tạo ra sự khác biệt cho các bên liên quan. Đó là nơi bạn muốn giữ mã của mình ở trạng thái hoàn hảo, sẵn sàng thực hiện yêu cầu tiếp theo với nỗ lực tối thiểu, do tính linh hoạt của Mô hình miền của bạn.

Tuy nhiên, điều đó sẽ tốn kém khi áp dụng cho tất cả các mã ứng dụng. Các lĩnh vực không có ý nghĩa đối với doanh nghiệp ( Các tên miền con hỗ trợ hoặc chung trong biệt ngữ DDD) có thể yêu cầu một cách tiếp cận ít phức tạp hơn so với khu vực dành riêng cho lõi.