Керівництво щодо структури проектів багатошарових програм MVVM, DDD та WPF

Я намагаюся налаштувати структуру свого додатка в VS і хочу "спробувати" і підтвердити це в майбутньому до розумного рівня. Ця програма буде перезаписом WPF старого додатка Winform, який не дотримувався жодних конвенцій. Без шарів, ярусів, абревіатур тощо ...

Це досить велика корпоративна програма. Я планував використовувати Linq To SQL як мій БД і, швидше за все, завжди буде MS SQL. Також у мене є наявний набір навичок з ним.

Я хочу дотримуватися MVVM та DDD якнайкраще, але я плутаюсь у структурі мого додатка при їх поєднанні. Дозвольте спробувати і проілюструвати на деяких прикладах.

Коли я слідую за MVVM, структура моєї папки може виглядати приблизно так:

Views
Models
ViewModels
Helpers

але як це вписується в спрощений DDD-шаруватий підхід, коли моя проектна структура може нагадувати таке:

MyApp.UI
MyApp.Domain
MyApp.Data

Чи потрібно розміщувати Modelsв шарі "Домен" чи у мене є 3 версії "say" Person? Це призводить до іншого питання, де я можу розмістити свій сховище та відображення об’єкта БД до об’єкта домену? Я б припустив, що дані ...

ViewsЯ можу ввійти в інтерфейс, але ViewModelsтакож?

Нарешті, куди я б вклав свою бізнес-логіку?

Я знайшов наступне на CodePlex, DDD Example , і це була деяка допомога, але, здається, це стосується веб-додатків, хоча це може не мати значення, і моє незнання світиться через.

Не зрозумійте мене неправильно, я знаю, що можу мати стільки папок і називати їх, що я хочу. Я намагаюся розібратися, де розмістити речі, щоб це було можливо в масштабах, а не в тому, що ці місця обов'язково називаються.

Серце мого запитання могло бути показане так.
У мене є tblPersonоб'єкт, породжений користувачем *.dbml. Це очевидно і належало б моєму шару "Дані".
Тепер я мав би Model, DTO, Domain Model, або як це називається в окремому шарі (проект?) Person. Я потрібно Mapperдля Personна tblPersonщо я не впевнений , куди подіти.
Тоді у мене з’явиться ViewModel для, скажімо, EditPersonщо він би мав власні властивості, з яких він витягується, Personале можливо і більше.
Нарешті, у мене з’явиться перегляд, який був пов'язаний з цим ViewModel ....

Щоб було зрозуміло, що абзац заповнений моїми припущеннями та здогадами, і я сподіваюся, що хтось допоможе очистити повітря для мене або запропонувати там розуміння, так що від 6 місяців до року я не б'ю себе більше, ніж мені потрібно.

MVVM - це шаблон інтерфейсу користувача та використовується у клієнті.

Частини домену в DDD, які використовуються в клієнті, ймовірно (частина) Моделі

Перегляд і ViewModel є лише клієнтом.

Я розміщую Репозиторії в (або поблизу) Моделі, оскільки вони синхронізують Модель із зворотною частиною.

Так, багато разів це призведе до декількох класів Person у різних просторах імен. Вони можуть почати дуже схожі, але можуть закінчитися дуже різними після декількох ітерацій чи випусків.

EDIT

Щоб уточнити частину про сховища та пояснити детальніше про позиціонування Business Logic

Якщо ви створюєте систему, яка містить окремі клієнтські та серверні / резервні сховища, можна використовувати в клієнті та сервері. У клієнті необхідно отримати абстракцію сервера (серверів), а в сервері - абстрагування інших серверів та джерел даних. Це просто візерунок.

Що стосується правил бізнесу: якщо ви використовуєте ті в клієнті, переконайтеся, що ви їх застосували і на сервері. Ніколи не довіряйте клієнту. Правила ведення бізнесу в клієнті дозволяють швидше перевірити вхід і запобігають зворотному переходу на сервер.

Я думаю, що DDD належить на стороні сервера і "протікає" клієнту.

Ви маєте правильний напрямок у виборі шаблону дизайну MVVM для застосування WPF.

Do I put the Models in the Domain layer?

Так, ваші моделі можна розмістити в домені

Where would I put my Repository and mappings of DB Object to Domain Object?

Ваші сховища можуть бути розміщені в шарі, де розміщений Ваш домен. Ваші об'єкти відображення (також звані DTOS - об'єкти передачі домену) повинні бути розміщені в вашому сервісному рівні , і ви можете використовувати потужний інструмент відображення AutoMapper легко зіставити об'єкти домену в DTOS.

ViewModels also?

Ваші ViewModels повинні бути розміщені на стороні вашого клієнта (шару). Ви можете побудувати свої моделі перегляду з одного або декількох DTO, залежно від ваших поглядів.

Щодо DDD , я б запропонував прочитати про це та уточнити, що вам дійсно потрібно мати шаблон дизайну, керований доменом. ось дискусія про те, що 95% усіх програмних програм належать до категорій «не дуже добре для використання DDD».

Редагувати: посилання було додано вище, і дякую за @Den!

Перш ніж ми поглибимося в те, що йде куди, давайте поговоримо про те, що повинен робити кожен шар.

Місце продажу MVVM є прив'язкою між видом і моделлю перегляду. Мета тут - усунути логіку всередині зору.
Як і Вигляд, Модель повинна бути досить легкою і використовувати її лише для доступу до інформації (даних), необхідної для роботи моделі перегляду. Модель може поєднувати доступ до різних джерел даних, але вона не повинна мати логіки бізнесу. У більшості випадків у вас є одне сховище даних. У деяких випадках ви цього не робите. Якщо цього не зробити, доцільно використовувати Модель, щоб затемнити джерело даних з VM.

Неявний пункт MVVM полягає в тому, що дані вже зберігаються і ваш проект не несе відповідальності за підтримку його організації. Деяким проектам пощастило відійти від цього припущення, більшість проектів, над якими я працював, не пощастило. Досить сказати, що Дані - це ще один шар, з яким нам доведеться боротися.

Я б виклав свій проект так:

 project.Views
 project.ViewModel
 project.Model
 project.DataStructs

і цей шар можна додавати в міру необхідності:

 project.Helpers

Я відокремлюю Helpers від решти стека, щоб він не плутався як шар вашої програми.

Відмова: Я не експерт DDD, але я розумію загальну суть і бачу цінність у підході.

Ваш домен стане проблемою, яку ви розглядаєте.
У моделі домену збирається відповідати в першу чергу до ViewModels , які ви створюєте; трохи в межах Переглядів; і невеликий шматок у моделі / DataStructs.

То як же це вийде?
Якщо у вас є можливість змінити існуючі структури даних, то нові, які ви створюєте, повинні відповідати проблемі, яку ви намагаєтеся вирішити. Отримали клієнтський об’єкт? Тоді ви повинні мати / кілька таблиць, пов’язаних із Замовником. Отримали рахунки чи товари? Та сама історія - слід створити таблиці та структури, які відображають ці бізнес-об’єкти.

Домен буде виражений через ваші об’єкти ViewModel та представлення представлень цих об’єктів. Якщо вам потрібно відредагувати записи клієнтів, у вас буде VM для вирішення цього завдання.

Ваші запитання:

1. Не намагайтеся накладати DDD на MVVM. Це просто не буде працювати. DDD - це не макет, це підхід до перегляду вашої загальної проблеми.
2. Репозиторій та відображення відображатимуться в будь-якому проекті.Дані або проекті. Модель відповідно.
3. Не майте шару під назвою UI, якщо це не те, що ви хочете викликати project.Views.
4. Бізнес-логіка піде у View-Model.