В настоящее время мне поручено разработать проект под n-уровневой архитектурой. Проект составлен следующим образом:
- Уровень представления (приложение для рабочего стола WPF, приложение для Android и веб-сайт с использованием
Угловой)
- Сервисный уровень (REST и SOAP)
- Бизнес-уровень
- Уровень доступа к данным - Использование в качестве базы данных Microsoft SQL Server и MongoDB.
Я в основном закончил делать общий дизайн проекта. В то время как в настоящее время сервис, бизнес и уровень доступа к данным будут выполняться по той же технологии (.NET). Он должен быть спроектирован так, чтобы я мог сделать любой слой по другой технологии.
В настоящее время у меня есть моя диаграмма Entity-Relationship, мой DTO и мой «домен». В настоящее время мои доменные классы похожи на мои DTO. В том смысле, что ни у них нет никакой логики внутри них. Они содержат только значения, но отличаются друг от друга, поскольку DTO более тесно связаны с тем, как я храню данные (не то же самое).
И мне трудно понять, что я должен поместить в свой бизнес-уровень, мудрый дизайн. (Я знаю, что это обрабатывает бизнес-логику).
Должны ли мои доменные классы быть внутри бизнес-логики и иметь сами методы, которые управляют бизнесом? Или я должен иметь разные классы, которые будут использовать мои модели / домен и обрабатывать там бизнес-логику?
Один из способов понять разницу между моими «моделями данных», DTO и «моделями доменов» - сказать себе: «Как я храню данные, как я передаю данные и как я обращаюсь с ними (бизнес) отличается ".