DDD ( Domain Driven Design ) — это набор шаблонов, принципов и практик, которые помогают нам решать и понимать бизнес-задачи (Domain) при проектировании объектно-ориентированных систем. DDD — очень обширная тема.
Я использую архитектуру N-Layers из Windows Forms, но в ASP.NET MVC у меня есть сомнения, так как я новичок, работающий с веб-системами.
Давайте сосредоточимся на архитектуре DDD.
Перейдем непосредственно к моей проблеме. Начиная с объектов предметной области, это объекты, которые имеют идентификатор и важны для бизнес-логики нашего приложения, но они не должны быть известны другим уровням приложения напрямую.
Это структура моего проекта.
Я использую DTO или объекты передачи данных — это классы, основная цель которых — упростить объекты, которыми будут обмениваться между процессами.
В Application Layer , в котором у меня есть два проекта: Application Services и Adapters .
- Адаптеры: здесь я реализовал свои DTO.
- Службы приложений: именно на этом уровне я реализую методы приложения, поскольку мой уровень представления не знает об уровне предметной области и наоборот. Возвращаясь к теме, именно на этом уровне я творю магию, превращая объекты домена в DTO с помощью AutoMapper.
Сущности домена.
public class Proveedor
{
public int ProveedorId { get; set; }
public string RazonSocial { get; set; }
public string Direccion { get; set; }
}
DTO
public class ProveedorDto
{
[Key]
public int ProveedorId { get; set; }
[Display(Name = "Razón Social")]
public string RazonSocial { get; set; }
[Display(Name = "Dirección")]
public string Direccion { get; set; }
}
Применение AutoMapper в Application Services.
public IEnumerable<ProveedorDto> GetAll()
{
IEnumerable<Proveedor> _proveedor = _sdProveedor.GetAll();
config = new MapperConfiguration(cfg => cfg.CreateMap<Proveedor, ProveedorDto>());
IEnumerable<ProveedorDto> listDto = config.CreateMapper().Map<IEnumerable<ProveedorDto>>(_proveedor);
return listDto;
}
Таким образом, мои объекты домена не достигают уровня представления, а DTO, находящиеся на уровне адаптеров, используются в качестве моделей шаблона проектирования MVC.
- Должен ли я создавать модели на уровне представления, должен ли я придерживаться письма о том, что модели реализованы на этом уровне, как говорит MVC?
- Как мне реализовать ту часть, которую я объяснил, используя передовой опыт, чтобы моя архитектура была аккуратной?
Я думаю, что важно четко понимать разницу между теорией и практикой. На протяжении всего приложения вы окажетесь во многих ситуациях, которые могут заставить вас нарушить эту теорию в погоне за производительностью и эффективностью. Это зависит от вас, как от архитектора приложения, чтобы принять это решение.
По моему личному опыту, модели ничего не рисуют на уровне представления. Я начал с того, что поместил их на персистентный слой, который является их идеальным местом, чтобы в итоге оказаться на поперечном слое под названием «Инфраструктура», поскольку так или иначе, было легко в конечном итоге нуждаться в их ссылках в других слоях. Теоретически все, что связано с персистентностью, включая модели, должно находиться на этом уровне. Домен не должен иметь никакого отношения к моделям или знать об их существовании.
Если вы архитектурный пурист и способны свести связь между слоями к нулю, вы достигли идеальной архитектуры, но я настаиваю на том, что много раз необходимо нарушать эти правила и делать все с головой. Когда пройдет время, и вы долго работаете с приложением, вы поймете, что вы сделали хорошо, а что нет.
Чувак
На самом деле все наоборот, все приложение должно знать домен. Идея DDD заключается в создании бизнес-модели, представляющей собой черный ящик, который работает и решает бизнес-задачи.
Таким образом, основное внимание уделяется созданию экосистемы, в которой объекты взаимодействуют и сотрудничают.
Чтобы было понятнее, концепция будет примерно такой: солнце своим собственным существованием оказывает влияние, его свет, его гравитация влияет на планеты, климат, поэтому каждое событие, происходящее в домене, должно быть таким.
В вашей модели это должно произойти, если у меня есть система учета, и счет-фактура должен вводиться при отправке сообщения в модель, которую он должен проверять, влиять на другие объекты и регистрировать при необходимости или, возможно, что-то изменять.
Вся эта логика инкапсулирована в предметную область таким образом, что операции не являются типичными:
_repisitorio.invoices.add(счет-фактура)
но
model.Invoices.RegistrarFactura(счет-фактура)
При генерации всей логики вы инкапсулируете ее в домен, способный выполнять свои собственные операции, что делает ее очень ценной.
Также важно упомянуть, что домен не имеет ничего общего с постоянством, потому что он должен иметь возможность работать без постоянства, даже если домен без постоянства почти бесполезен.
Теперь причина использования преобразований домена в пользовательский объект заключается в том, что в mvc результаты выполняются через модель представления, а в домене концепция может включать своего рода сотрудничество между бизнес-объектами, что не делает ее кандидатом для представления пользователю.
например, у вас может быть заказ на покупку и его элементы, и пользователю из пользовательского интерфейса отображается заказ на покупку и количество элементов, очевидно, это должно быть обработано, и результат заполнит модель представления, готовую к отображению
Еще одна важная концепция заключается в том, что, сосредоточившись на Домене, мы больше не говорим об изолированных концепциях, например, до того, как для чего-то было характерно иметь такие сущности, как
Эмп теперь сотрудник. Просто, верно?
Сущности должны быть общими для всех людей в команде, это то, что называется вездесущим языком, можно сказать, что в разговорном языке не должно быть абстракций, как это было раньше, но вы должны иметь возможность поговорить с бизнес-экспертом. об одних и тех же понятиях.
Также важно, что для моделирования домена он не рождается в вашей голове, домен бизнеса всегда уже существует, что делается, это разговаривать с теми, кто знает бизнес, а затем это передается в код, поэтому важно хорошо понимать, как это работает, если невозможно оставить пустым и, следовательно, не решить все проблемы.
Прочтите книгу Эрика Эванса «Дизайн доменного диска».
Ложь, они видны на всех уровнях, но пользователю не обязательно их знать.
Должен ли я создавать модели на уровне представления, должен ли я придерживаться письма о том, что модели реализованы на этом уровне, как говорит MVC?
Так как это реализовано в mvc никакого отношения к ddd не имеет, но важный момент, действия тесно связаны с моделью представления, которая, как следует из ее названия, является моделью представления, то есть страницы, которая имеет ничего общего с вашим доменом, потому что его причиной является представление или страница, и эта концепция обрабатывается в mvc.
Как мне реализовать ту часть, которую я объяснил, используя передовой опыт, чтобы моя архитектура была аккуратной?
Рецепта нет, вы должны документировать себя.
Для страниц mvc используются пользовательские модели представления, которые представляют собой модель, разработанную для этой веб-страницы и заполненную данными объектов домена, которые являются DTO. Вы делаете запрос на бизнес-уровень, который возвращает объект предметной области (dto), и вы сопоставляете его со своей настраиваемой моделью представления. Таким образом, вы создаете локальные модели для своих веб-страниц по своему вкусу, которые могут питаться одним или несколькими объектами предметной области.