Trách nhiệm duy nhất (lý do để thay đổi) của một thực thể nên được xác định duy nhất chính nó, nói cách khác, trách nhiệm của nó là có thể tìm thấy.
Cuốn sách DDD của Eric Evan, pg. 93:
trách nhiệm cơ bản nhất của các Thực thể là thiết lập tính liên tục để hành vi có thể rõ ràng và có thể dự đoán được. Họ làm điều này tốt nhất nếu họ được giữ lại. Thay vì tập trung vào các thuộc tính hoặc thậm chí là hành vi, hãy loại bỏ định nghĩa của đối tượng Thực thể xuống các đặc điểm nội tại nhất, đặc biệt là các đặc điểm nhận dạng nó hoặc thường được sử dụng để tìm hoặc khớp với nó. Chỉ thêm hành vi cần thiết cho khái niệm và thuộc tính được yêu cầu bởi hành vi đó.
Ngoài ra, hãy tìm cách loại bỏ hành vi và thuộc tính vào các đối tượng khác được liên kết với Thực thể cốt lõi. Các vấn đề nhận dạng. Các thực thể có xu hướng thực hiện trách nhiệm của mình bằng cách phối hợp hoạt động của các đối tượng mà chúng sở hữu.
1.
... loại bỏ định nghĩa của đối tượng ENTITY xuống các đặc điểm nội tại nhất, đặc biệt là các đặc điểm nhận dạng nó hoặc thường được sử dụng để tìm hoặc khớp với nó. Chỉ thêm hành vi cần thiết cho khái niệm ...
Khi một thực thể được gán một ID duy nhất , danh tính của nó được thiết lập và vì vậy tôi cho rằng một thực thể đó không cần bất kỳ hành vi nào để duy trì danh tính của nó hoặc để giúp nhận dạng chính nó . Vì vậy, tôi không hiểu loại hành vi nào được tác giả đề cập đến (bên cạnh findvà match hoạt động ) với " hành vi cần thiết cho khái niệm "?
2.
... loại bỏ định nghĩa của đối tượng ENTITY xuống các đặc điểm nội tại nhất, đặc biệt là các đặc điểm nhận dạng nó hoặc thường được sử dụng để tìm hoặc khớp với nó. ... Ngoài ra, hãy tìm cách loại bỏ hành vi và thuộc tính vào các đối tượng khác được liên kết với ENTITY cốt lõi.
Vì vậy, bất kỳ hành vi nào không giúp xác định thực thể, nhưng chúng tôi vẫn mô tả hành vi đó là một đặc điểm nội tại của thực thể đó (tức là sủa là nội tại đối với chó, bay là nội tại đối với máy bay, đẻ trứng là nội tại đối với chim .. .), nên được đưa vào các đối tượng khác được liên kết với thực thể đó (ví dụ: chúng ta nên đặt hành vi sủa vào một đối tượng liên quan đến thực thể chó)?
3.
Ngoài ra, hãy tìm cách loại bỏ hành vi và thuộc tính vào các đối tượng khác được liên kết với ENTITY cốt lõi.
a) MyEntityủy thác trách nhiệm A_respvà B_respcho các đối tượng avà b, tương ứng.
Mặc dù hầu hết A_respvà B_respcông việc được thực hiện bởi avà các btrường hợp, khách hàng vẫn được phục vụ A_respvà B_respthông qua MyEntity, điều đó có nghĩa là từ quan điểm của khách hàng, hai trách nhiệm thuộc về MyEntity. Vì vậy, điều đó không có nghĩa là MyEntitycũng có A_respvà B_resptrách nhiệm và như vậy là vi phạm SRP ?
b) Ngay cả khi chúng tôi cho rằng A_respvà B_respkhông thuộc về MyEntity, MyEntityvẫn có trách nhiệm AB_respđiều phối hoạt động của các đối tượng avà b. Vì vậy, không MyEntityvi phạm SRP vì tối thiểu nó có hai trách nhiệm - để xác định duy nhất chính nó và cả AB_resp?
class MyEntity
{
private A a = ...
private B b = ...
public A GetA()
{ ... }
public B GetB()
{ ... }
/* coordinates operations of objects a and b */
public int AworkB()
{ ... }
}
/* A encapsulates a single responsibility resp_A*/
/* A is value object */
class A
{ ... }
/* B encapsulates a single responsibility resp_B*/
/* B is value object */
class B
{ ... }
CẬP NHẬT:
1.
Hành vi trong bối cảnh này là đề cập đến hành vi ngữ nghĩa. Ví dụ: Thuộc tính trên một lớp (tức là thuộc tính trên một đối tượng miền) được sử dụng để xác định duy nhất nó có hành vi. Trong khi điều này không được đại diện trong mã trực tiếp. Hành vi dự kiến là sẽ không có bất kỳ giá trị trùng lặp nào cho thuộc tính đó.
Vì vậy, trong mã, chúng ta hầu như không bao giờ cần phải thực hiện một hành vi (tức là một hoạt động) bằng cách nào đó duy trì danh tính thực thể, vì như bạn đã giải thích một hành vi như vậy chỉ tồn tại như một khái niệm trong mô hình miền (dưới dạng thuộc tính ID của một thực thể), nhưng khi chúng tôi dịch thuộc tính ID này thành mã, một phần ngữ nghĩa của nó bị mất (tức là phần ngầm đảm bảo giá trị ID là duy nhất bị mất)?
2.
Furthmore, một tài sản như Age không có bối cảnh bên ngoài một Thực thể Người, và do đó, không có ý nghĩa gì khi di chuyển vào một đối tượng khác ... Tuy nhiên, thông tin đó có thể dễ dàng được lưu trữ ở một vị trí riêng biệt mà định danh duy nhất, do đó tham chiếu khó hiểu cho hành vi. Tuổi có thể là một giá trị tải lười biếng.
a) Nếu thuộc Agetính được tải lười biếng, thì chúng ta có thể gọi nó là một hành vi, mặc dù về mặt ngữ nghĩa Agechỉ là một thuộc tính?
3.
Bạn có thể dễ dàng có các hoạt động cụ thể cho Địa chỉ, chẳng hạn như xác minh rằng đó là một địa chỉ hợp lệ. Bạn có thể không biết rằng tại thời điểm thiết kế, nhưng toàn bộ khái niệm này là chia nhỏ các đối tượng thành các phần nhỏ nhất của chúng
Mặc dù tôi đồng ý rằng chúng ta sẽ mất bối cảnh bằng cách di chuyển Agevào các đối tượng khác nhau, bối cảnh sẽ không bị mất nếu chúng ta chuyển DateOfBirthtài sản sang một đối tượng khác, nhưng chúng ta thường không di chuyển nó.
Lý do chính khiến chúng ta chuyển Addresssang một đối tượng khác, nhưng không phải là DateOfBirthgì? Bởi vì DateOfBirththực chất hơn đối với Personthực thể hoặc bởi vì có ít cơ hội hơn mà ở đâu đó trong tương lai chúng ta có thể cần xác định các hoạt động cụ thể DateOfBirth?
4. Tôi phải nói rằng tôi vẫn không biết liệu MyEntitycũng có A_respvà B_resptrách nhiệm hay không và tại sao MyEntitycũng AB_respkhông được coi là vi phạm SRP
EULERFX
1)
Các hành vi mà tác giả đang đề cập đến là các hành vi liên quan đến thực thể. Đây là những hành vi sửa đổi trạng thái của thực thể
a) Nếu tôi hiểu bạn một cách chính xác, bạn đang nói rằng thực thể đó chỉ nên chứa những hành vi sửa đổi các thuộc tính của nó (tức là trạng thái của nó )?
b) Và những hành vi không nhất thiết phải sửa đổi trạng thái của thực thể , nhưng vẫn được coi là một đặc tính nội tại của thực thể đó (ví dụ: sủa sẽ là đặc điểm nội tại của một Dogthực thể, ngay cả khi nó không sửa đổi Trạng thái của chó )? Chúng ta nên bao gồm những hành vi này trong một thực thể hay chúng nên được chuyển sang các đối tượng khác?
2)
Theo như hành vi di chuyển đến các đối tượng khác, tác giả đang đề cập đến các đối tượng giá trị cụ thể.
Mặc dù trích dẫn của tôi không bao gồm nó, nhưng tác giả có đề cập trong cùng một đoạn rằng trong một số trường hợp, các hành vi (và thuộc tính ) cũng sẽ được chuyển sang các thực thể khác (mặc dù tôi hiểu lợi ích của việc chuyển hành vi sang VO)
3) Giả sử MyEntity(xem câu hỏi 3. trong bài viết gốc của tôi) không vi phạm SRP, chúng tôi có nói rằng trách nhiệm thuộc về MyEntitynhững điều khác cũng bao gồm:
a. A_resp + B_resp + AB_resp ( AB_resptọa độ đối tượng avà b)
hoặc là
b. AB_resp + ủy thác A_respvà B_respcho các đối tượng ( avà b) liên kết với MyEntity?
4) Cuốn sách DDD của Eric Evan, pg. 94:
CustomerID là số nhận dạng duy nhất và duy nhất của ENTITY của khách hàng (hình 5.5), nhưng số điện thoại và địa chỉ thường được sử dụng để tìm hoặc khớp với Khách hàng. Tên không xác định danh tính của một người, nhưng nó thường được sử dụng như một phần của phương tiện xác định nó.
Trong ví dụ này, các thuộc tính điện thoại và địa chỉ được chuyển vào Khách hàng, nhưng trên một dự án thực tế, lựa chọn đó sẽ phụ thuộc vào cách khách hàng của tên miền thường được khớp hoặc phân biệt. Ví dụ: nếu Khách hàng có nhiều số điện thoại liên hệ cho các mục đích khác nhau, thì số điện thoại đó không được liên kết với danh tính và nên ở lại với Liên hệ bán hàng.
a)
CustomerID là số nhận dạng duy nhất và duy nhất của ENTITY của khách hàng (hình 5.5), nhưng số điện thoại và địa chỉ thường được sử dụng để tìm hoặc khớp với Khách hàng. Tên không xác định danh tính của một người, nhưng nó thường được sử dụng như một phần của phương tiện xác định nó.
Trích dẫn rằng chỉ các thuộc tính liên quan đến danh tính nên ở trong một thực thể . Tôi giả sử tác giả có nghĩa là thực thể chỉ nên chứa những thuộc tính thường được sử dụng để tìm hoặc khớp với thực thể này , trong khi TẤT CẢ các thuộc tính khác nên được di chuyển?
b) Nhưng các thuộc tính khác nên được di chuyển như thế nào? Ví dụ: giả định ở đây là thuộc tính địa chỉ không được sử dụng để tìm hoặc khớp Customer và do đó chúng tôi muốn chuyển thuộc tính địa chỉ ra khỏi Customer):
nếu thay vì có Customer.Address(loại string) chúng ta tạo một Customer.Addressthuộc tính loại Address, chúng ta đã di chuyển thuộc tính địa chỉ vào một đối tượng VO có liên quan (thuộc loại Address) hay chúng ta sẽ nói rằng Customervẫn chứa thuộc tính địa chỉ ?
c)
Trong ví dụ này, các thuộc tính điện thoại và địa chỉ được chuyển vào Khách hàng, nhưng trên một dự án thực tế, lựa chọn đó sẽ phụ thuộc vào cách khách hàng của tên miền thường được khớp hoặc phân biệt. Ví dụ: nếu Khách hàng có nhiều số điện thoại liên hệ cho các mục đích khác nhau, thì số điện thoại đó không được liên kết với danh tính và nên ở lại với Liên hệ bán hàng.
Không được tác giả trong sai ở đây, vì nếu chúng ta giả định mỗi trong số rất nhiều số điện thoại liên lạc mà Customerchỉ có thuộc về đó đặc biệt Customer, sau đó tôi muốn nói những số điện thoại có liên quan đến danh tính cũng giống như khi Customerchỉ có một số điện thoại ?
5)
Lý do tác giả đề xuất tước thực thể xuống là khi ban đầu tạo ra một thực thể Khách hàng, có xu hướng cư trú với bất kỳ thuộc tính nào mà người ta có thể nghĩ là có liên quan đến khách hàng. Đây là một cách tiếp cận tập trung vào dữ liệu mà bỏ qua các hành vi cuối cùng dẫn đến một mô hình miền thiếu máu.
Tắt chủ đề, nhưng tôi nghĩ rằng mô hình miền thiếu máu kết quả từ chuyển hành vi ra khỏi một thực thể , trong khi ví dụ bạn đang Populating một thực thể với nhiều thuộc tính , điều này sẽ dẫn đến Customerviệc có quá nhiều hành vi (kể từ khi chúng tôi có lẽ cũng bao gồm trong Customercác hành vi đó sửa đổi các thuộc tính bổ sung này ) và do đó vi phạm SRP?
cảm ơn