Вопросы с тегом «domain-driven-design»

Проектирование на основе доменов (DDD) - это подход к разработке программного обеспечения для сложных задач путем соединения реализации с развивающейся моделью.

2
DDD - Совокупный корень с большим количеством детей
Я предрежу этот вопрос, сказав, что я относительно новичок в DDD, поэтому я могу сделать здесь несколько фундаментальных ошибок! Я работаю над проектом, который включает в себя концепции счетов и транзакций (в финансовом смысле). Счет может иметь много транзакций против него. Мне кажется, что Учетная запись и Транзакция являются обеими …

2
В хранилище или не в хранилище
Когда я впервые узнал о Domain Driven Design, меня также познакомили с репозиторием и шаблонами рабочих единиц, которые когда-то казались первоклассными для крутых ребят, которые бросали SQL-запросы, например, пещерные люди, в базы данных. Чем глубже я углубился в эту тему, тем больше я узнал, что они больше не нужны, поскольку …


1
Заменяют ли ORM POCO доменные объекты?
Это несколько похоже на этот вопрос, но более широко. В целом, если ORM, такие как EF 4.1, поддерживают POCO, имеет ли смысл теперь, чтобы ваши доменные объекты были объектами, которые сохраняются в вашей базе данных? В более старых ORM, таких как EF 4 или Linq-to-SQL, ваши «объекты базы данных» генерировались …

1
Как применить некоторые концепции DDD к реальному коду? Конкретные вопросы внутри
Я изучал DDD, и в настоящее время я пытаюсь найти способ применить концепции в реальном коде. У меня около 10 лет опыта работы с N-ярусом, поэтому очень вероятно, что я борюсь за то, что моя ментальная модель слишком связана с этим дизайном. Я создал веб-приложение Asp.NET и начинаю с простого …

4
DDD подход к базовым операциям CRUD в сложном доменно-ориентированном приложении
Моя компания переписывает наше веб-приложение с нуля. Это крупное приложение уровня предприятия со сложной областью в финансовой индустрии. Мы используем ORM (Entity Framework) для сохранения. По сути, половина наших приложений сосредоточена на сборе необработанных данных от пользователя, их хранении, а затем другая половина приложения, содержащая большую часть нашей реальной доменной …

3
Является ли плохой практикой для определения объекта API содержать сторонние ссылочные идентификаторы в качестве свойств?
Нравится: Campaign: type: object properties: id: type: string description: "A GUID identifier" referenceId: type: string description: "A consumers identifier they have used to map their own systems logic to this object." name: type: string description: "'Great Campaign 2017' as an example" Я обеспокоен ссылкой . Системный домен представляет собой платформу, …

4
Как четко определить границы ограниченного контекста
После месяца или около того чтения и исследования DDD я решил начать свой собственный проект и создал DDD с этими ограниченными контекстами> клиенты Товары заказы Billing Каждый ограниченный контекст имеет API покоя в качестве уровня представления, уровня домена, постоянного уровня. Пока все хорошо, код работает гладко, но, исходя из монолитного …

2
Должен ли хорошо известный бизнес-идентификатор объекта быть представлен специальным типом в DDD / OOP?
В практическом плане это означает использование пользовательского (неизменяемого) classнад stringили каким-либо другим примитивным типом. Примеры: Издательство: Международный стандартный номер книги. Финансы: международный идентификационный номер ценных бумаг. Преимущества: Может обеспечить формат идентификатора. Становится первоклассным представителем модели. Недостатки: Добавляет постоянство трения (например, Entity Framework). Больше кода

4
Модель отношений с DDD (или со смыслом)?
Вот упрощенное требование: Пользователь создает Questionс несколькими Answerс. Questionдолжен быть хотя бы один Answer. Уточнение: подумайте Questionи Answerкак в тесте : есть один вопрос, но несколько ответов, где немногие могут быть правильными. Пользователь - это актер, который готовит этот тест, поэтому он создает вопросы и ответы. Я пытаюсь смоделировать этот …

2
DDD: Могут ли неизменные объекты быть сущностями?
Я читал бесчисленные посты о различиях между сущностями и объектами-значениями, и хотя я думаю, что, по крайней мере, концептуально я понимаю, как они различаются, похоже, что в некоторых из этих постов авторы считают, что концепция конкретного домена является ВО, просто потому, что является неизменным (таким образом, его состояние никогда не …

4
Обеспечение согласованности транзакций с DDD
Я начинаю с DDD и понимаю, что совокупные корни используются для обеспечения транснациональной согласованности. Мы не должны изменять несколько агрегатов в одном сервисе приложений. Однако я хотел бы знать, как справиться со следующей ситуацией. У меня есть совокупный корень под названием Продукты. Существует также совокупный корень, называемый группой. Оба имеют …

2
Должны ли мы высмеивать сущности и объекты стоимости при выполнении DDD?
После прочтения нескольких статей о Newable против Контурных объектов и как эти понятия относятся к услугам для DDD, организациям и объектам стоимости, я остался с некоторыми сомнениями об использовании newables в моем коде , особенно в моих модульных тестах. Основными кандидатами для newables были объекты Entities и Value. Это означает, …

3
Презентация VS Прикладной уровень в DDD
У меня проблемы с проведением четкой грани между уровнем представления и приложениями в дизайне, управляемом доменом. Куда должны идти файлы Controllers, Views, Layouts, Javascript и CSS? Это на уровне приложения или презентации? И если они объединяются в одном слое, что содержит другой? Это пусто?

3
DDD и объекты значения. Изменчивые Объекты Значения - хороший кандидат для Non Aggr. Корневая сущность?
Вот небольшая проблема Иметь сущность со значением объекта. Не проблема. Я заменяю объект-значение новым, затем nhibernate вставляет новое значение и теряет значение старого, а затем удаляет его. Хорошо, это проблема. Застрахованным является моя сущность в моем домене. У него есть коллекция адресов (объектов значения). Одним из адресов является MailingAddress. Когда …

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.