2009-04-21 50 views
21

Tôi chắc chắn 80% tôi không nên đặt câu hỏi này bởi vì nó có thể xảy ra như là tiêu cực và tôi có nghĩa là không thiếu tôn trọng bất cứ ai, đặc biệt là tác giả của cuốn sách này. Tôi đã xem một số bài đăng đề xuất số book và người bạn đồng hành project. Tôi chưa đọc cuốn sách, nhưng tôi đã dành một vài giờ để nghiên cứu dự án. Và trong khi nó trông rất hoàn chỉnh, tôi đang có một thời gian rất khó khăn với bao nhiêu chi tiết của những thứ khác nhau nằm rải rác xung quanh. Tôi đang vật lộn trong thiết kế của riêng mình với bao nhiêu tôi phải thay đổi nếu một thực thể thay đổi, và dự án này không làm cho tôi rất thoải mái như một giải pháp.Đây có phải là DDD không?

Ví dụ: có đối tượng Nhân viên kế thừa từ một cá nhân. Người có một nhà xây dựng với tên, họ, vv và do đó, nhân viên cũng vậy. Riêng tư cho nhân viên là thành viên cho tên, họ, cộng với tài sản công cộng cho cùng.

Có một EmployeeFactory biết về cả thuộc tính Nhân viên và Người, cũng như tên cột SQL (để lấy giá trị từ trình đọc).

Có một EmployeeRepository với các phương thức PersistNewItem và PersistUpdatedItem chưa được thực hiện mà tôi nghi ngờ, nếu được triển khai, sẽ xây dựng SQL cho các câu lệnh INSERT và UPDATE như tôi thấy trong CompanyRepository. Chúng viết các thuộc tính cho các chuỗi để xây dựng SQL.

Có một 'Hợp đồng dữ liệu' PersonContract với cùng thành viên riêng tư và thuộc tính công khai như Person và EmployeeContract kế thừa từ PersonContract như Employee does Person, với thuộc tính công cộng phản ánh các thực thể.

Có một 'Chuyển đổi' lớp tĩnh với các phương pháp tĩnh mà bản đồ các đơn vị tham gia hợp đồng, bao gồm

EmployeeContract ToEmployeeContract(Employee employee) 

mà các bản sao các lĩnh vực từ một đến khác, bao gồm các lĩnh vực Person. Có thể có một phương pháp đồng hành đi theo cách khác - không chắc chắn.

Tôi nghĩ rằng cũng có các bài kiểm tra đơn vị.

Trong tất cả, tôi đếm 5-10 lớp, phương pháp và nhà thầu với kiến ​​thức chi tiết về các thuộc tính thực thể. Có lẽ chúng được tạo tự động - không chắc chắn. Nếu tôi cần thêm 'Salutation' hoặc tài sản khác vào Person, tôi sẽ phải điều chỉnh tất cả các lớp/phương thức này? Tôi chắc chắn tôi sẽ quên điều gì đó.

Một lần nữa, tôi có nghĩa là không thiếu tôn trọng và điều này có vẻ là một ví dụ chi tiết, kỹ lưỡng cho cuốn sách. Đây có phải là cách DDD được thực hiện không?

+1

Nhân tiện, tôi đã bình chọn bạn vì tôi nghĩ đó là một câu hỏi * tuyệt vời *. –

Trả lời

9

DDD mới đủ (ít nhất là trong một số giác quan) có thể hơi sớm để nói chính xác "cách thực hiện". Ý tưởng của chúng tôi đã diễn ra trong một thời gian dài, mặc dù chúng tôi không tạo nên một cái tên hay cho nó.

Trong mọi trường hợp, câu trả lời ngắn (IMAO) là "có, nhưng ...." Ý tưởng thực hiện thiết kế theo tên miền là mô hình hóa miền rất rõ ràng. Những gì bạn đang xem là một mô hình miền, đó là để nói một mô hình hướng đối tượng mô tả miền vấn đề trong ngôn ngữ của miền của vấn đề. Ý tưởng là một mô hình miền, vì nó mô hình hóa "thế giới thực", tương đối không nhạy cảm với sự thay đổi và cũng có xu hướng bản địa hoá thay đổi. Vì vậy, nếu ví dụ như ý tưởng của bạn về những gì một Nhân viên thay đổi, có lẽ bằng cách thêm địa chỉ gửi thư cũng như địa chỉ thực, thì những thay đổi đó sẽ được địa phương hóa tương đối.

Một khi bạn có mô hình đó, tuy nhiên, bạn có những gì tôi duy trì là các quyết định kiến ​​trúc vẫn được thực hiện. Ví dụ, bạn có lớp persistence chưa thực hiện, mà thực sự có thể chỉ đơn giản là xây dựng SQL.Nó cũng có thể là một lớp Hibernate, hoặc sử dụng Python tẩy, hoặc thậm chí là một cái gì đó hoang dã giống như một cấu trúc bảng phân phối Google AppEngine.

Vấn đề là, các quyết định đó được thực hiện riêng biệt và với các lý do khác, so với các quyết định lập mô hình miền.

Điều tôi đã thử nghiệm với một số kết quả tốt là làm mô hình miền bằng Python và sau đó xây dựng mô phỏng với nó thay vì triển khai hệ thống cuối cùng. Điều đó làm cho một cái gì đó mà khách hàng có thể thử nghiệm, và cũng có khả năng cho phép bạn đưa ra các ước tính định lượng về những điều mà việc thực hiện cuối cùng phải xác định.

+1

Tôi không nghĩ rằng nó thực sự là bất cứ điều gì mới mẻ, quá mới mẻ đối với dòng mã hóa thương mại (đặc biệt). Thiết kế ngôn ngữ cụ thể cho miền (trong một ngôn ngữ lập trình thích hợp) và các mô hình đối tượng hướng miền đã là bánh mì và bơ hoạt động trong một số cộng đồng ngôn ngữ trong nhiều thập kỷ. – simon

+0

Địa ngục, ngay cả trong công việc thương mại, ít nhất một số nơi. Tôi đã đẩy "mô hình miền cấp tiến" tại IBM Consulting vào đầu những năm 90. –

+0

Dường như với tôi rằng phần lớn những gì chúng ta nói đến là các thuật ngữ mới cho những ý tưởng không phải là mới. Nhưng đó là ok - đôi khi nó có một tên tốt để thúc đẩy một ý tưởng tốt. – n8wrl

14

Thiết bị điều khiển tên miền thực sự đơn giản. Nó nói: làm cho các lớp mô hình của bạn phản chiếu thế giới thực. Vì vậy, nếu bạn có nhân viên, có một lớp nhân viên và chắc chắn rằng nó có chứa các thuộc tính cung cấp cho nó 'Employee-ness' của nó.

Câu hỏi mà bạn đang yêu cầu KHÔNG phải là về DDD, mà là về kiến ​​trúc lớp nói chung. Tôi nghĩ bạn đúng khi đặt câu hỏi về một số quyết định về các lớp bạn đang xem, nhưng nó không liên quan đến DDD cụ thể. Nó liên quan nhiều hơn đến các mẫu thiết kế lập trình OOP nói chung.

+0

Điểm tốt. Tôi đoán như những người khác đã tuyên bố, đó là về sự cân bằng - mục tiêu của việc cô lập 'nhân viên-ness' là mâu thuẫn với việc phân tách các mối quan tâm. Lớp kiên trì có lẽ phải biết về sự 'ngán ngợp' của nhân viên cũng như giao diện người dùng, v.v. Vì vậy, nó có thể không có khả năng làm nổi bật nó nhiều như nó cảm thấy đúng. – n8wrl

+0

Tôi không nghĩ đó là sự thật. Các lớp kiên trì cần biết cách duy trì nội dung, và đó là nó. Trong điều kiện duy nhất cụ thể thực hiện mà kiên trì cần biết có thể là các bảng cơ sở dữ liệu, các bảng cơ sở dữ liệu và các cột của chúng không cần biết bất kỳ điều gì về hành vi của một nhân viên. Họ chỉ cần biết cách lưu trữ và truy xuất dữ liệu của một Nhân viên. Điều quan trọng là giữ cho hành vi của miền cụ thể ra khỏi lớp kiên trì, nếu không bạn không thể kiểm tra nó. – RibaldEddie

+4

Theo dõi: bạn có quyền đặt câu hỏi liệu Nhân viên có nên phân loại Người hay không. Tôi không nghĩ rằng nó nên. Một người nên có vai trò, và nhân viên là một vai trò như vậy. Phân lớp phụ sẽ mở ra một hộp sâu. Hãy xem xét rằng nếu bạn cần thay đổi Person-ness trong mô hình miền của bạn, bạn cũng sẽ thay đổi Employee-ness, ngay cả khi thay đổi không có liên quan gì đến Employee-ness. Thừa kế, sử dụng kém, làm cho mô hình miền yếu hơn. Thừa kế, sử dụng kém, làm cho phần mềm tồi tệ hơn. – RibaldEddie

8

với tôi, điều làm cho DDD khác với thiết kế hướng "mô hình" là khái niệm "rễ tổng hợp", tức là một ứng dụng là chỉ được phép giữ tham chiếu đến tổng hợp và nói chung bạn sẽ chỉ có một kho lưu trữ cho lớp gốc tổng hợp, không phải các lớp mà tổng hợp gốc sử dụng

điều này làm sạch mã đáng kể; thay thế là kho lưu trữ cho mỗi lớp mô hình, đó là "chỉ đơn thuần" một thiết kế lớp, không phải DDD

Các vấn đề liên quan