На мою думку, це абсолютно не так, як це мається на увазі. І це порушення DRY.
Ідея полягає в тому, щоб об'єкт / об'єкт домену посередині моделювався, щоб представити домен максимально добре та максимально зручно. Він знаходиться в центрі всього і все може залежати від цього, оскільки сам домен не змінюється більшу частину часу.
Якщо ваша база даних ззовні може зберігати ці об’єкти безпосередньо, то відображення їх у інший формат заради розділення шарів не просто безглуздо, а створення дублікатів моделі, і це не є наміром.
Для початку, чиста архітектура була зроблена з іншим типовим середовищем / сценарієм на увазі. Програми для бізнес-серверів із зовнішніми шарами, які потребують власних типів спеціальних об'єктів. Наприклад, бази даних, які створюють SQLRowоб'єкти і потребують SQLTransactionsвзамін оновлення елементів. Якщо ви використовуєте ті, хто знаходиться в центрі, ви повинні порушити напрямок залежності, оскільки ваше ядро залежатиме від бази даних.
З легкими ОРМ-кодами, які завантажують і зберігають об'єкти об'єктів, це не так. Вони роблять відображення між внутрішнім SQLRowта вашим доменом. Навіть якщо вам потрібно помістити @Entitiyанотацію ORM до вашого доменного об’єкта, я стверджую, що це не встановлює "згадки" зовнішнього шару. Оскільки анотації - це лише метадані, жоден код, який спеціально не шукає їх, не побачить їх. І що ще важливіше, нічого не потрібно змінювати, якщо ви вилучите їх або заміните іншою анотацією до бази даних.
На відміну від цього, якщо ви змінили свій домен і зробили всі ці картографи, вам доведеться багато чого змінити.
Поправка: Вище трохи спрощена і навіть може бути помилковою. Тому що є частина чистої архітектури, яка хоче, щоб ви створили представлення на кожен шар. Але це потрібно бачити в контексті заявки.
А саме наступне тут https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html
Важливим є те, що окремі, прості структури даних передаються через межі. Ми не хочемо обманювати та передавати рядки Entities або Database. Ми не хочемо, щоб структури даних мали будь-яку залежність, яка б порушувала правило Dependency.
Проходження сутностей від центру до зовнішніх шарів не порушує правила залежності, проте вони згадуються. Але це є причиною в контексті передбаченої заяви. Передача сутностей навколо перемістить логіку програми назовні. Зовнішні шари повинні знати, як інтерпретувати внутрішні об'єкти, вони повинні ефективно робити те, що має робити внутрішні шари, такі як шар "використання випадку".
Крім того, він також розв'язує шари, так що зміни в ядрі не обов'язково потребують змін у зовнішніх шарах (див. Коментар SteveCallender). У цьому контексті легко зрозуміти, як саме об'єкти повинні представляти мету, для якої вони використовуються. Крім того, ці шари повинні говорити один з одним щодо об'єктів, створених спеціально для цього повідомлення. Це навіть може означати, що є 3 зображення, по 1 у кожному шарі, 1 для транспортування між шарами.
І є https://blog.8thlight.com/uncle-bob/2011/11/22/Clean-Architecture.html, адреса якої вище:
Інші люди стурбовані тим, що чистим результатом моїх порад буде багато дублюваного коду та велика кількість копіювання даних із однієї структури даних в іншу по всіх шарах системи. Звичайно, я теж цього не хочу; і нічого, що я запропонував, неминуче призвело б до повторення структур даних і до непомірного копіювання на місцях.
ІМО означає, що просто копіювання об'єктів 1: 1 - це запах в архітектурі, оскільки ви насправді не використовуєте належні шари та / або абстракції.
Пізніше він пояснює, як уявляє всі "копіювання"
Ви відокремлюєте інтерфейс користувача від бізнес-правил, передаючи прості структури даних між ними. Ви не повідомляєте контролерам нічого про правила бізнесу. Натомість контролери розпаковують об'єкт HttpRequest в просту структуру даних ванілі, а потім передають цю структуру даних об'єкту-інтерактору, який реалізує випадок використання, викликаючи бізнес-об’єкти. Потім інтерактор збирає дані відповіді в іншу структуру даних ванілі і передає їх назад в інтерфейс користувача. Погляди не знають про бізнес-об’єкти. Вони просто заглядають у цю структуру даних і представляють відповідь.
У цій програмі існує велика різниця між представленнями. Дані, що надходять, не є лише сутностями. І це вимагає різних класів.
Однак застосовано до простого додатка Android, наприклад, для перегляду фотографій, у якого Photoорганізація має близько 0 бізнес-правил, а "випадок використання", який займається ними, майже не існує і насправді більше стурбований кешуванням та завантаженням (цей процес повинен бути IMO представлене більш явно), пункт робити окремі уявлення про фотографію починає зникати. Я навіть відчуваю, що саме фотографія є об'єктом передачі даних, тоді як реальний бізнес-логічний ядро-шар відсутній.
Існує відмінність "відокремити інтерфейс користувача від правил бізнесу, передавши прості структури даних між двома" і ", коли ви хочете відобразити фотографію, перейменуйте її 3 рази на шляху" .
Крім того, я бачу, що ці демонстраційні програми не вдається представити чисту архітектуру - це те, що вони додають величезного акценту на розділення шарів заради розділення шарів, але ефективно приховують те, що робить додаток. Це на відміну від сказаного в https://blog.8thlight.com/uncle-bob/2011/09/30/Screaming-Architecture.html, а саме -
архітектура програмного забезпечення кричить про випадки використання програми
Я не бачу такого акценту на розділенні шарів в чистій архітектурі. Йдеться про напрямок залежності та зосередження уваги на представленні основи програми - сутностей та випадків використання - в ідеальній простоті Java без залежностей від зовнішньої сторони. Справа не стільки в залежності від цього ядра.
Тож якщо у вашій програмі насправді є ядро, яке представляє ділові правила та випадки використання, та / або різні люди працюють на різних шарах, будь ласка, розділіть їх за призначенням. Якщо ви, з іншого боку, просто пишете просту програму, не перестарайтеся. 2 шари з плавними рамками можуть бути і більш ніж достатніми. І шари можна також додати пізніше.
BankAccountале з певними правилами програми, що ви можете зробити з цим обліковим записом.