Alt.Net Seattle – Takeaway<DDDD>().Resources

As other attendees have alluded to, one of the better questions from that came from the session was “How do you move a team that’s used to working with a request/response architecture to a domain driven messaged based architecture?”

I thought Martin Fowler answered the question very well:

“Anything that causes a state change to my world, my domain model? I capture in an object, you can think of it as a command object, I like to think of it as an event object. That object carries with it all the information about the kind of state change it might be. Then I have some way of processing it against my domain model to actually perform the change, but I still store and persist that event object as part of the record of what I?ve done.? DDDD video, 49:00ish

He are a couple of great articles from Martin’s site which elaborate on his statement, if you are interested in making the transition from request/response to messaging I recommend giving them both a thorough read. I am currently in the process of making the transition myself and I found them very helpful.

Fowler – Event Sourcing

Fowler – Event Collaboration


Also from the session came a great list of other reading materials, so bone up!

Pattern Oriented Software Architecture Books 1-4

Enterprise Integration Patterns 

Domain Driven Design 

Domain Driven Design Quickly (Free 100 page compressed version in PDF provided by InfoQ)

Power of Events

Distributed Event Based Systems

Event Based Programming

Software Architecture in Practice (weighing ‘ilities’)

SEI – Quality Attributes (PDF)


Thanks to all the attendees including Evan Hoff, Udi Dahan and Greg Young for helping compile the great list of books you see above. (as well as their contributions to the conversation in general)

4 thoughts on “Alt.Net Seattle – Takeaway<DDDD>().Resources

  1. The best resource for getting your feet wet with software quality attributes is to read the book Software Architecture in Practice. The PDFs on the SEI website are great, but I don’t think you’ll get the broad picture from reading them alone.

    For example, when working with stakeholders on a new system, it’s often useful to define a Utility tree to help guide architecture decisions. If the project is very large, a Quality Attribute Workshop might actually help the project drive out some risk. Another tool where quality attributes are used is in doing Architecture Evalutions. This entails an evaluation activity that’s designed to drive nonfunctional risks out of large development projects.

    These things are all related to quality attributes, but if you go for the PDFs alone, you’ll miss them (even at an introductory level).

Comments are closed.