Єдиною відповідальністю (підставою для зміни) суб'єкта господарювання повинно бути унікальна ідентифікація себе, іншими словами, його відповідальність полягає у фіналізації.
Книга DDD Еріка Евана, стор. 93:
Основна відповідальність суб'єктів господарювання полягає у встановленні наступності, щоб поведінка була чіткою та передбачуваною. Вони роблять це найкраще, якщо їх залишають запасними. Замість того, щоб концентруватись на атрибутах чи навіть на поведінці, зніміть визначення об'єкта 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обов'язки, і як таке порушує СРП ?
б) Навіть якщо ми припустимо , що A_respі B_respне належать MyEntity, по- MyEntity, як і раніше несе відповідальність AB_respза координацію операцій об'єктів aі b. Тож не MyEntityпорушує СРП, оскільки як мінімум він несе два обов'язки - однозначно ідентифікувати себе, а також 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 у код, частина його семантики втрачається (тобто частина, яка неявно переконує, що значення ID унікальне втрачено)?
2.
Далі, така властивість, як Age, не має контексту поза особою особи, і, як така, не має сенсу переходити в інший об'єкт ... Однак ця інформація може легко зберігатися в окремому місці, яке є унікальним ідентифікатором, отже заплутане посилання на поведінку. Вік може бути лінивим значенням.
а) Якщо 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), але телефонний номер та адреса часто використовуються для пошуку або відповідності Клієнту. Ім'я не визначає особу людини, але її часто використовують як частину засобів її визначення.
У цьому прикладі атрибути телефону та адреси переміщені до Клієнта, але в реальному проекті цей вибір залежатиме від того, яким чином клієнти домену зазвичай відповідають або розрізняються. Наприклад, якщо у Клієнта є багато контактних номерів телефонів для різних цілей, то номер телефону не пов’язаний з посвідченням особи і повинен залишатися з Контактом з продажу
а)
CustomerID - це єдиний ідентифікатор ENTITY Клієнта (рисунок 5.5), але телефонний номер та адреса часто використовуються для пошуку або відповідності Клієнту. Ім'я не визначає особу людини, але її часто використовують як частину засобів її визначення.
Цитата зазначає, що лише атрибути, пов’язані з ідентичністю, повинні залишатися в сутності . Я припускаю, що автор означає, що сутність повинна містити лише ті атрибути , які часто використовуються для пошуку або відповідності цій сутності , тоді як ВСІ інші атрибути слід переміщувати?
б) Але як / куди слід переміщувати інші атрибути ? Наприклад (припущення тут полягає в тому, що атрибут адреси не використовується для пошуку або збігу, Customer і тому ми хочемо перемістити атрибут адреси з Customer):
якщо б замість того, щоб мати Customer.Address(тип string), ми створимо властивість Customer.Addressтипу Address, чи перенесли ми атрибут адреси в асоційований об'єкт VO (який є типу Address) чи скажемо, що він Customerвсе ще містить атрибут адреси ?
в)
У цьому прикладі атрибути телефону та адреси переміщені до Клієнта, але в реальному проекті цей вибір залежатиме від того, яким чином клієнти домену зазвичай відповідають або розрізняються. Наприклад, якщо у Клієнта є багато контактних номерів телефонів для різних цілей, то номер телефону не пов’язаний з посвідченням особи і повинен залишатися з Контактом з продажу
Тут не помиляється автор, оскільки якщо припустити, що кожен із багатьох контактних телефонів, що Customerналежать лише цьому конкретному Customer, я б сказав, що ці телефонні номери пов'язані з ідентичністю так само, як і тоді, коли Customerбув лише один номер телефону ?
5)
Причина, яку автор пропонує зняти суб'єкт господарювання, полягає в тому, що коли спочатку створюється суб'єкт Замовника, існує тенденція до заповнення його будь-яким атрибутом, який можна вважати асоційованим із клієнтом. Це підхід, орієнтований на даних, який не враховує поведінки, що в кінцевому рахунку призводить до анемічної моделі домену.
За темі, але я думав , що анемія моделі предметної області результатів від переміщення поведінки з - за суті , в той час як ваш приклад заповненням в об'єкт з великою кількістю атрибутів , які привели б Customerмати занадто багато поведінки (так як ми, ймовірно , також включаємо в Customerтих поведениях , які змінити ці додаткові атрибути ) і, таким чином, порушувати SRP?
Дякую