devTeach Talk

Here is my devTeach talk … I got a bit of a late start and had a lot of material to try to get in so I had to push away from a few good discussions but I will answer those discussions in a post here … and be kind I only knew I was speaking 2 weeks in advance 😉

 

Enjoy!

 

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

16 Responses to devTeach Talk

  1. Mike Fuller says:

    Very interesting and paradigm shifting video. Any prospect of a white paper being produced as was suggested near the end of the video.

    Thanks.

    Mike.

  2. Rick Hoskins says:

    Nice talk.
    I had to implement a similar system a few years ago (different domain). My motives for such a system were needing regular access to (snapshot ) historical points, and managing data changes from other systems that were committed out there, and coming in to my system at very long delay intervals, such as 12 hours+ (needing the consistency, or ability to make “who’s right” choices).
    Sometimes these things are not possible to avoid.

    I had no focus on DDD at all, in fact I don’t think it really was a “known thing” at the time, at least in the windows world.

    When talking about it with other people, I found it useful to get them to consider Active Directory, NDS, and other similar systems (distributed directories), rather than SQL servers, RDBMS, etc, but then I was used to dealing with globally distributed directories, with all of the problems they face.

    I designed the system over a period of time by working thru the requirements and really putting a lot of hard thinking into the problem, and then at the end realised .. hey, I know ALL about this from a past life in the internals of directory systems! Once the penny dropped everything made perfect sense, and there is quite a lot of information on the issues such systems face, out there.
    I wonder though, how many developers know about how such systems work, nowadays. Certainly, explaining it to pure RDBMS folks got me lots of strange looks and comments. It felt the same watching this presentation video :) Some of the things that are necessary to do really feel unnatural to traditional RDBMS thinking.

    I love the flexibility such a system gives you regarding historical information (your object event log). It’s possible to show the state of the system / a set of objects /etc, at any given historical point in time, something I think is sadly missing from RDBMS without a lot of hastle. Temporal DBs haven’t made it to the mainstream, either.

    Do you know of any codebase implementing such a system out there in open source land for c# / dotnet ? My system was in Delphi.

  3. Ollie Riches says:

    Hi Greg, do you provide these as downloads at all?

  4. Thanks, Greg. I was also able to find out a little more about Event Sourcing here…

    http://martinfowler.com/eaaDev/EventSourcing.html

  5. Greg says:

    but its also quite easy to work around that issue in other ways (like not giving them a way to send messages until they are loaded)

  6. Greg says:

    Mark, they know the difference between an initial load and processing.

  7. Hi Greg. Very nice presentation. Your recent DDDD posts along with other presentations have me very intrigued with the ideas presented.

    One question regarding the entities being loaded from store (at approx minute 41:30). If I understand you right, whenever you want to reload an object from store, you create a new object, then alter the object message-by-message until you are back to the current, committed state.

    Perhaps I’ve missed something, but wouldn’t that mean that these entites are resending old messages? For example, when you have a Customer that went through three state changes (you created it, you changed it’s address, and you sent it a spring catalog), and the entity, when it’s address is changed, sends out an AddressChanged message, wouldn’t you, by replaying the commands on your new entity, end up sending out a duplicate AddressChanged message?

    First off, am I right in assuming that entities in the domain model ARE indeed the ones who send out messages (even if it’s through some interface that doesn’t expose the message-passing implementation)? It seems that the sending of messages is, indeed, a domain concern. Thus, assuming that they are, is whatever interface they use to send out the message just “turned off” when you are reconstituting an entity, so that those duplicate messages are not sent out, and then turned back on when it’s considered back to working, comitted order?

  8. Greg says:

    re: last comment (not published) its not that its such at long and drawn out story its just that this is the wrong medium to be having the conversation over.

    You can email be directly at the email above if you like.

    Greg

  9. Greg says:

    I will refrain from going into the whole story here on my blog but if you want to hear it you can email me at grezgzoryzyoung1@gzmail.com remove the zs

  10. Robin says:

    Long story? I thought either you are married or you aren’t?

    Unless you married someone so they could stay in the country? Robin is confused!!!

  11. Greg says:

    Long story Robin ….

  12. Robin says:

    Are you really married?

  13. Ray says:

    Very nice. Thanks Greg

  14. Kevin Miller says:

    Watching…

    Do you have a link to the Powerpoint? I am really enjoying the presentation but having problems seeing the slides.

  15. Casey says:

    An excellent talk! I like a lot of the ideas presented … and Oren’s questioning made it doubly entertaining :)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>