Запитання з тегом «domain-driven-design»

Чи можете ви сказати мені свою думку про те, який шар є правильним розмістити обробники подій домену в DDD? Наприклад, у мене є служба додатків, щоб додати новий контракт, і я хотів би надіслати електронною поштою сповіщення контактній особі, коли договір буде доданий, як це відправник електронної пошти (який обробляє …

13 domain-driven-design  event 

У дизайні, керованому доменом, у шарі домену можуть бути декілька (традиційних) послуг. Наприклад, для домену Користувача ми можемо мати: UserFactory, який будує об’єкти користувача різними способами UserRepository, який відповідає за взаємодію зі службами збереження в інфраструктурному шарі Чи є UserService в доменному шарі просто посередником та / або фасадом для …

13 object-oriented  object-oriented-design  domain-driven-design 

Я занурився в концепцію дизайну, керованого доменом (DDD), і виявив деякі принципи дивними, особливо стосовно ізоляції доменної та стійкої моделі. Ось моє основне розуміння: Служба на рівні додатків (надає набір функцій) запитує доменні об’єкти із сховища, яке йому потрібно для виконання своєї функції. Конкретна реалізація цього сховища отримує дані з …

13 domain-driven-design  domain-model  persistence 

Типова реалізація сховища DDD не виглядає дуже OO, наприклад save()метод: package com.example.domain; public class Product { /* public attributes for brevity */ public String name; public Double price; } public interface ProductRepo { void save(Product product); } Інфраструктурна частина: package com.example.infrastructure; // imports... public class JdbcProductRepo implements ProductRepo { private …

12 design-patterns  object-oriented  domain-driven-design 

По-перше, відмова від відповідальності: я не знаю, чи відповідає це питання цьому веб-сайту, але я все ще вважаю актуальним питання не лише до мене, але і для інших, хто є початківцями. Якщо питання можна вдосконалити, щоб відповідати тут, будь ласка, зверніть увагу на int коментарі. Якщо це не підходить, дайте …

12 architecture  object-oriented-design  domain-driven-design  requirements  engineering 

Постійність Ігнорування - це застосування принципу єдиної відповідальності, що на практиці означає, що об’єкти домену ( DO ) не повинні містити код, пов'язаний із стійкістю, натомість вони повинні містити лише логіку домену. а) Я припускаю, що це означає, що код, який контактує з нижчими шарами (тобто стійкими шарами), знаходиться поза …

12 design-patterns  domain-driven-design  domain-model  persistence 

Я читав про DDD вже цілими днями і мені потрібна допомога з цим зразком дизайну. Усі правила DDD мене дуже заплутують у тому, як я повинен будувати що-небудь взагалі, коли об’єкти домену не дозволяють показувати методи на рівні додатків; де ще організувати поведінку? Репозиторіям не можна вводити суб'єкти, і самі …

12 architecture  domain-driven-design 

Ми намагаємось перенести дані з нашого розширеного сервісного рівня в наш доменний рівень, використовуючи підхід DDD. Наразі у наших послугах є велика ділова логіка, яка розповсюджується всюди і не отримує користі від успадкування. У нас є центральний клас доменів, який є основною частиною нашої роботи - торгівля. Об'єкт Торгівлі буде …

12 object-oriented  design  domain-driven-design 

Нещодавно я прочитав багато аргументів проти використання шаблону репозиторію з потужним ORM, як Entity Framework, оскільки він містить функціонал схожих на сховища, а також функціонал Unit of Work. Інший аргумент проти використання шаблону для такої ситуації, як тестування одиниць, полягає в тому, що модель сховища є протікаючою абстракцією, оскільки більш …

12 domain-driven-design  entity-framework  orm  nhibernate  repository-pattern 

Я в основному намагаюся обернути голову навколо концепції CQRS та пов'язаних з цим понять. Хоча CQRS не обов'язково включає в себе повідомлення та обмін подіями, це здається гарною комбінацією (як це можна побачити з великою кількістю прикладів / блогових постів, що поєднують ці поняття) Враховуючи випадки використання для зміни стану …

12 domain-driven-design  cqrs  event-sourcing 

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

12 object-oriented  php  programming-practices  domain-driven-design 

Багато навчальних посібників з DDD, який я вивчав, здебільшого охоплюють теорію. Всі вони мають рудиментарні приклади коду (Pluralsight та подібні). В Інтернеті також є спроби кількох людей створити навчальні посібники, що охоплюють DDD за допомогою EF. Якщо ви почнете їх вивчати лише коротко - ви швидко помітите, що вони сильно …

12 c#  design-patterns  object-oriented-design  domain-driven-design  entity-framework 

Як я розумію, в DDD доречно використовувати шаблон сховища з сукупним коренем. Моє запитання полягає в тому, чи слід повертати дані як об'єкт або доменні об'єкти / DTO? Можливо, якийсь код пояснить моє питання далі: Суб'єкт public class Customer { public Guid Id { get; set; } public string FirstName …

11 c#  domain-driven-design  repository-pattern 

Я хочу реалізувати свою першу заявку за допомогою шаблону CQRS разом із пошуком подій. Мені цікаво, як зі створенням сукупних коренів слід правильно поводитися. Скажімо, хтось надсилає команду CreateItem. Як з цим поводитися? Де подію ItemCreate слід зберігати? Як перша подія нового предмета? Або я повинен мати якусь сутність ItemList, …

11 domain-driven-design  repository  cqrs  event-sourcing 

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

11 architecture  domain-driven-design  wcf  soa  modules