Loading ...
Sorry, an error occurred while loading the content.

Re: DDD Community Essay: Effective Aggregate Design

Expand Messages
  • sweetlandj
    Scalability. And event store is append only, so there is very little contention for resources (maybe a page lock on an index during an insert). Therefore the
    Message 1 of 41 , Dec 6, 2011
    View Source
    • 0 Attachment
      Scalability. And event store is append only, so there is very little contention for resources (maybe a page lock on an index during an insert). Therefore the commands can execute and persist very fast without having to wait for shared read locks to clear.

      Once the events are appended to the event store, they are published asynchronously and are handled by separate threads or processes (possibly on different servers) to update their local read stores. These updates are the only writes that occur against the read stores, and they occur much less frequently than reads, so most read queries should be able to get shared read locks on the resources they need and execute very quickly.

      The idea is that you divide your app into two (or more) data stores: one append-only event store to which you can write without worrying about read locks; and one or more read-only (*except for event updates) data stores that you can read from without waiting for exclusive update locks to clear. This mitigates blocking, deadlock, and other related issues that occur in normal RDBMS systems.


      --- In domaindrivendesign@yahoogroups.com, "i_adore_serena" <serenarules@...> wrote:
      >
      > Pardon me for the intrusion into this thread Vernon, but I noticed the topic is focusing now on consistency, and it relates to some of the issues I have with event sourcing. You you mind giving me your take on my statements below?
      >
      > Eventual consistency is a major reason why I am having difficulties with event sourcing. While the overall concept is wonderful, I am a bit too pragmatic for it I think. At least, in the way the it is usually defined. Pre-event sourcing, in a command handler, once a method is called on a business object, I would always just save the object using a unit of work. This is imediate. So when I started looking at event sourcing, I had a hard time straying from this ideal. Once the business method was called, without generating exceptions, I want to immediately call send on the event bus to persist the changes I just validated and applied. Having done that, it makes sense to also immediately persist the actual events. Some people argue that this might cause sequencing errors, but I can't see how. If my business method caused two events to be generated, those events would be persisted in the same order the were generated. If another user makes additional changes, at the same time I do, but hits the save button first, their events will be persisted just before mine. Still no problem. Considering that I really don't like the idea of storing events in a queue, and that they are all being immediately persisted, whenever an object is requested, it is rebuilt completely from persisted events. So the next time I, or that other person, loads the object, we will see the results of both our sets of changes.
      >
      > So why is eventual consistency such a focal point with event sourcing? It seems to introduce more levels of complexity and points of failure than it solves.
      >
      >
      > --- In domaindrivendesign@yahoogroups.com, Raoul Duke <raould@> wrote:
      > >
      > > On Mon, Dec 5, 2011 at 8:41 PM, vvernon_shiftmethod
      > > <vvernon@> wrote:
      > > > I did. I commented on one example of when it works, and one example of when it doesn't work well. Perhaps there are ways to solve the problem in some domains, but it seems to greatly complicate things to force it. Eventual consistency works fine in a lot of cases.
      > >
      > > as a slow-brained programmer, i kinda have a strong distaste for
      > > eventual consistency. too damned hard to understand and debug and make
      > > sure that the inconsistencies are the right allowed kinds vs. actual
      > > serious bugs.
      > >
      >
    • vvernon_shiftmethod
      Hey Mike, That video seems to load a bit slowly for some reason, but it did work for me. It is also here, but I don t know if this one is just a link or if it
      Message 41 of 41 , Jul 17, 2012
      View Source
      • 0 Attachment
        Hey Mike,

        That video seems to load a bit slowly for some reason, but it did work for me. It is also here, but I don't know if this one is just a link or if it is actually hosted:

        http://dddcommunity.org/library/vernon_2012

        There was a little problem at the end of the video where my voice goes out of sync. I call it the Godzilla movie effect ;)

        Vaughn



        --- In domaindrivendesign@yahoogroups.com, "mike_mccarthy3" <mike_mccarthy3@...> wrote:
        >
        > this video is not loading for me. Is it available anywhere else?
        >
        > --- In domaindrivendesign@yahoogroups.com, "vvernon_shiftmethod" <vvernon@> wrote:
        > >
        > > My Effective Aggregate Design--Part III presentation video from this past Monday has been posted:
        > >
        > > http://vimeo.com/36884903
        > >
        > > At the end of the presentation I talk at some length about my book. I think you'd enjoy some details, including early availability on Safari Books Online.
        > >
        > > Enjoy!
        > >
        > > Vaughn
        > >
        > > --- In domaindrivendesign@yahoogroups.com, "vvernon_shiftmethod" <vvernon@> wrote:
        > > >
        > > > Effective Aggregate Design--Part III has been released. See the dddcommunity site:
        > > >
        > > > http://dddcommunity.org/library/vernon_2011
        > > >
        > > > Vaughn
        > > >
        > > >
        > > > --- In domaindrivendesign@yahoogroups.com, "vvernon_shiftmethod" <vvernon@> wrote:
        > > > >
        > > > > In his DDD Summit 2011 review, Eric stated: "There was interest in producing a set of prescriptive rules of thumb for common design decisions in how to execute a domain-driven design."
        > > > >
        > > > > Here's a link to the paper I contributed:
        > > > >
        > > > > http://dddcommunity.org/library/vernon_2011
        > > > >
        > > > > The first part of the three-part series is available now as a PDF. The remaining two parts are to be released over the next few months. The paper reflects the insights of the Summit group, and has been reviewed by most of them. Eric provided some very valuable editorial. I think it addresses many of the common questions about aggregates that arise on the group.
        > > > >
        > > > > Vaughn
        > > > >
        > > >
        > >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.