Единственная ответственность (причина изменения) организации должна заключаться в том, чтобы однозначно идентифицировать себя, иными словами, ее ответственность должна быть обнаруживаемой.
DDD книга Эрика Эвана, стр. 93:
основная ответственность Сущностей заключается в установлении преемственности, с тем чтобы поведение могло быть четким и предсказуемым. Они делают это лучше всего, если их держать запасными. Вместо того, чтобы фокусироваться на атрибутах или даже поведении, разделите определение объекта Entity до наиболее внутренних характеристик, особенно тех, которые его идентифицируют или обычно используются для его нахождения или сопоставления. Добавьте только поведение, которое необходимо для концепции и атрибутов, которые требуются для этого поведения.
Помимо этого, обратите внимание на удаление поведения и атрибутов в другие объекты, связанные с основной сущностью Entity. Помимо проблем идентификации, сущности стремятся выполнять свои обязанности, координируя операции объектов, которыми они владеют.
1.
... обрезать определение объекта ENTITY до самых внутренних характеристик, особенно тех, которые его идентифицируют или обычно используются для его нахождения или сопоставления. Добавьте только поведение, которое необходимо для концепции ...
Как только объекту присваивается уникальный идентификатор , его личность устанавливается, и поэтому я предполагаю, что такому объекту не нужно какое-либо поведение, чтобы поддерживать свою идентичность или помогать ему идентифицировать себя . Таким образом, я не понимаю , что такое поведение является автор со ссылкой на (помимо findи match операции ) с « поведением , что имеет существенное значение для концепции »?
2.
... обрезать определение объекта ENTITY до самых внутренних характеристик, особенно тех, которые его идентифицируют или обычно используются для его нахождения или сопоставления. ... Помимо этого, обратите внимание на удаление поведения и атрибутов в другие объекты, связанные с ядром ENTITY.
Таким образом, любое поведение, которое не помогает идентифицировать сущность, но мы все равно охарактеризовали бы это поведение как внутреннюю характеристику этой сущности (то есть лай присущ собакам, полет присущ самолетам, откладка яиц присущ птицам). .), должны ли быть помещены в другие объекты, связанные с этой сущностью (пример: мы должны поместить поведение лая в объект, связанный с сущностью собаки)?
3.
Помимо этого, посмотрите, чтобы удалить поведение и атрибуты в другие объекты, связанные с ядром ENTITY.
а) MyEntityделегирует обязанности A_respи B_respобъектам aи b, соответственно.
Хотя большинство A_respи B_respработа выполняется , aи bслучаи, клиенты по - прежнему служили A_respи B_respчерез MyEntity, что означает , что с точки зрения клиента две обязанности принадлежат MyEntity. Таким образом, разве это не означает, что MyEntityтакже имеет A_respи B_respобязанности и как таковое нарушает SRP ?
б) Даже если мы предположим, что A_respи B_respне принадлежим MyEntity, по- MyEntityпрежнему несет ответственность AB_respза координацию операций объектов aи b. Так что не MyEntityнарушает ли SRP, поскольку как минимум у него есть две обязанности - однозначно идентифицировать себя, а также 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
{ ... }
ОБНОВИТЬ:
1.
Поведение в этом контексте относится к семантическому поведению. Например, свойство класса (т. Е. Атрибут объекта домена), которое используется для однозначной идентификации, имеет поведение. Пока это не представлено в коде напрямую. Ожидаемое поведение заключается в том, что для этого свойства не будет повторяющихся значений.
Таким образом, в коде нам практически никогда не потребуется реализовывать поведение (т. Е. Операцию), которое каким-то образом будет поддерживать идентичность объекта, поскольку, как вы объяснили, такое поведение существует только как концепция в модели предметной области (в форме атрибута ID объект), но когда мы переводим этот атрибут ID в код, часть его семантики теряется (т. е. часть, которая неявным образом обеспечивает уникальность значения идентификатора, теряется)?
2.
Кроме того, такое свойство, как Age, не имеет контекста вне Entity Entity, и, как таковое, не имеет смысла перемещаться в другой объект ... Однако эта информация может легко храниться в отдельном месте, в котором находится уникальный идентификатор, следовательно, запутанная ссылка на поведение. Возраст может быть лениво загруженным значением.
а) Если Ageсвойство загружено с отложенной загрузкой, то мы можем назвать его поведением, даже если семантически Ageэто просто атрибут?
3.
Вы могли бы легко иметь операции, специфичные для Адреса, такие как проверка того, что это действительный адрес. Вы можете не знать об этом во время разработки, но вся эта концепция состоит в том, чтобы разбивать объекты на их мельчайшие части.
Хотя я согласен, что мы потеряли бы контекст, перейдя Ageв другой объект, контекст не был бы потерян, если бы мы переместили DateOfBirthсвойство в другой объект, но мы обычно не перемещаем его.
Какова основная причина, по которой мы бы переместились Addressв другой объект, но нет DateOfBirth? Потому что DateOfBirthэто более присуще Personсущности или потому что есть меньше шансов, что где-то в будущем нам может понадобиться определить операции, специфичные для DateOfBirth?
4. Я должен сказать , что я до сих пор не знаю, MyEntityесть также A_respи B_respобязанности и почему MyEntityже то , AB_respне считается нарушением SRP
EULERFX
1)
Поведения, на которые ссылается автор, - это поведения, связанные с сущностью. Это поведения, которые изменяют состояние объекта
а) Если я вас правильно понимаю, вы говорите, что сущность должна содержать только те поведения, которые изменяют ее атрибуты (то есть ее состояние )?
б) А как насчет поведения, которое не обязательно изменяет состояние объекта , но все же рассматривается как внутренняя характеристика этого объекта (пример: лай будет внутренней характеристикой Dogобъекта, даже если он не изменяет его) Собачье состояние )? Должны ли мы включить эти поведения в объект или они должны быть перемещены в другие объекты?
2)
Что касается перемещения поведения к другим объектам, автор имеет в виду конкретно объекты значения.
Хотя моя цитата не включает его, но автор упоминает в том же абзаце, что в некоторых случаях поведение (и атрибуты ) также будут перемещены в другие сущности (хотя я понимаю преимущества переноса поведения в ВО)
3) Если предположить MyEntity(см вопрос 3. в моей должности) не нарушает SRP, бы мы говорим , что ответственность в MyEntityэто помимо всего прочего , также состоящих из:
а. A_resp + B_resp + AB_resp ( AB_respкоординаты объектов aи b)
или
б. AB_resp + делегирование A_respи B_respобъектам ( aи b) связанным с MyEntity?
4) DDD книга Эрика Эвана, стр. 94:
CustomerID - это единственный идентификатор Клиента ENTITY (рисунок 5.5), но номер телефона и адрес часто используются для поиска или сопоставления Клиента. Имя не определяет личность человека, но оно часто используется как часть средств его определения.
В этом примере атрибуты телефона и адреса перенесены в Customer, но в реальном проекте этот выбор будет зависеть от того, как клиенты домена обычно сопоставляются или различаются. Например, если у клиента много контактных телефонных номеров для разных целей, тогда этот номер телефона не связан с идентификационной информацией и должен оставаться в контакте с отделом продаж.
а)
CustomerID - это единственный идентификатор Клиента ENTITY (рисунок 5.5), но номер телефона и адрес часто используются для поиска или сопоставления Клиента. Имя не определяет личность человека, но оно часто используется как часть средств его определения.
Quote состояния , что только атрибуты , связанные с идентичностью должны оставаться в сущности . Я предполагаю, что автор означает, что сущность должна содержать только те атрибуты , которые часто используются для поиска или сопоставления этой сущности , тогда как ВСЕ другие атрибуты должны быть перемещены?
б) Но как / куда следует перемещать другие атрибуты ? Например (здесь предполагается, что атрибут address не используется для поиска или сопоставления, Customer и поэтому мы хотим вывести атрибут адреса из Customer):
если вместо того, чтобы Customer.Address(типа string) мы создали свойство Customer.Addressтипа Address, мы перенесли бы атрибут адреса в связанный объект VO (который имеет тип Address) или мы бы сказали, что он Customerвсе еще содержит атрибут адреса ?
с)
В этом примере атрибуты телефона и адреса перенесены в Customer, но в реальном проекте этот выбор будет зависеть от того, как клиенты домена обычно сопоставляются или различаются. Например, если у клиента много контактных телефонных номеров для разных целей, тогда этот номер телефона не связан с идентификационной информацией и должен оставаться в контакте с отделом продаж.
Не автор в неправильном здесь, так как если мы предположим , каждый из многочисленных контактных телефонов , которые Customerимеют только принадлежу к этому частности Customer, то я бы сказал , что эти телефонные номера связаны с идентичностью так же , как тогда , когда Customerбыл только один номер телефона ?
5)
Причина, по которой автор предлагает сократить сущность, заключается в том, что при первоначальном создании сущности «Клиент» существует тенденция к заполнению ее любым атрибутом, который можно представить связанным с покупателем. Это ориентированный на данные подход, который игнорирует поведение, в конечном итоге приводящее к модели анемичной области.
По теме, но я думал , что анемия модели предметной области результатов от перемещения поведения из - за сущности , в то время как ваш пример заполнением в объект с большим количеством атрибутов , которые привели бы Customerиметь слишком много поведения (так как мы, вероятно , также включаем в Customerтех поведениях , которые изменить эти дополнительные атрибуты ) и, следовательно, в нарушение SRP?
Благодарность