Wrox Programmer Forums

Need to download code?

View our list of code downloads.

| FAQ | Members List | Search | Today's Posts | Mark Forums Read
BOOK: Patterns, Principles and Practices of Domain-Driven Design
This is the forum to discuss the Wrox book Patterns, Principles and Practices of Domain-Driven Design by Scott Millett; ISBN: 978-1-118-71470-6
Welcome to the p2p.wrox.com Forums.

You are currently viewing the BOOK: Patterns, Principles and Practices of Domain-Driven Design section of the Wrox Programmer to Programmer discussions. This is a community of tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developers’ questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
DRM-free e-books 300x50
Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old November 10th, 2017, 08:10 AM
Registered User
Points: 5, Level: 1
Points: 5, Level: 1 Points: 5, Level: 1 Points: 5, Level: 1
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
Join Date: Nov 2017
Posts: 1
Thanks: 0
Thanked 0 Times in 0 Posts
Default Returning Domain Event Pattern

I have a some questions concerning the returning domain event pattern (chapter 18).

1-How should the DB transactions shoule be handle?
Transaction must be handle in application services. So I can do some actions on an aggregate root at this layer, persisting it in the DB, closing the transaction, and handling the accumulated domain events on the aggregate after that, using a dispatcher. But is it the responsability of the dispatcher to create new transaction, one for each event it process, or should the processing of an event be wrapped in a transaction at the same level where we iterate on the domain events returned by the aggregate (in the application service)?

2-What is your opinions about hooking the transaction completion using the ORM (i.e.: IPostInsertEventListener, IPostDeleteEventListener, IPostUpdateEventListener of NHibernate) instead of manually doing it in the application service? Does it add too much coupling? Is it better because it does not require the same code being written at each use case (the domain event looping on the aggregate and potentially the new transaction creation if it is not inside the dispatcher)?
Reply With Quote

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Having a Domain Event update the UI?‏ livewire BOOK: Patterns, Principles and Practices of Domain-Driven Design 3 February 11th, 2016 05:41 PM
State pattern versus Strategy Pattern disel2010 BOOK: Professional ASP.NET Design Patterns 2 March 15th, 2011 08:20 AM
Event-based Asynchronous Pattern sfx BOOK: Professional C# 2008 ISBN: 978-0-470-19137-8 0 March 1st, 2009 02:06 AM
Event based notification pattern jimbeam36 .NET Web Services 1 December 14th, 2004 02:05 PM
DirectoryInfo.GetFiles(pattern): search pattern fo arif_1947 VS.NET 2002/2003 1 October 19th, 2004 11:59 PM

All times are GMT -4. The time now is 11:38 PM.

Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.