Greg Young at Devnology

Yesterday I attended a Distributed Domain Driven Design presentation given by Greg Young and organized by devnology at Xebia office. In the past I have been playing with DDD concepts but a lot of questions remained unanswered, even after asking them to Eric Evans when he was at the Xebia office a few years ago.

The information provided by Greg made a lot of sense and it was nice to see that there is a better way for writing domain driven applications instead of the current often awkward approach. Creating different models for different needs and storing the event chain instead of storing the new state of an object really made sense. So it is certainly something I want to experiment with in the future. The well known “Patterns of Enterprise Application Architecture” written by Martin Fowler and “Domain-Driven Design: Tackling Complexity in the Heart of Software” written by Eric Evans, made the first steps in the enterprise domain driven design possible, but I think that Greg could lead us to the next step.

Apart from the technical content (very very important to me) it was also nice to see an enthusiastic and professional speaker. I would certainly place him in the same league as Fowler and Evens and I think that we are going to hear more about Greg in the future (a book perhaps?).

5 Responses to Greg Young at Devnology

  1. Maninder says:

    Hi Peter, i am currently doing a project which is based on DDD concepts. I am very curious to know greg’s viewpoint on DDD. Would you be able to share some of the distinction or refinement which Greg did over evan’s book?

    Thank you.

    • pveentjer says:

      Hi Maninder,

      one of the most important things I learned on that evening is that instead of dealing a domain objects with all kinds of logic, is that it is easier to deal with the events that trigger that logic.

      For example, when an Employee gets a raise, I could call the method setSalary. But according to DDDD it is better to create an event called Raise for example. This Raise event also is stored in the database, instead of the actual content of the Employee object. If for some unlucky reason this person is fired, instead of removing the person from the database, or flipping over some kind of ‘fired’ flag, just store the Fired event on top of the previous happened events.

      So you get the audit trail for free! If you want to get the actual state of the Employee for example (what is his salary, or is he still working here), just replay the event trail. To prevent replaying too many events, you can add some kind of snapshot in between that reflect the state of a Employee at some point in time. So if you want to see the state of an Employee, look for the newest snapshot and replay all the events that happened after that snapshot was taken.

      Another thing I learned is that using the same datamodel for manipulation (so firing employees for example) and for viewing (some kind of webpage) is not a good thing (duh). So create a database optimised for storing and retrieving events (essentially this is the god-database). And if you need a database for viewing, just create another one and push all the events to this view database and map them to some kind of or-model.

      The views can directly talk to an database completely optimised for their needs and the same goes for the modifications.

      Greg can explain this a lot better than I can. I guess that there is better documentation (perhaps even pod-casts) that explain this in a lot more detail.

  2. Maninder says:

    Hi Peter,
    We are doing something similar, only the sequence is different. My application is based on command pattern. hence, when we receive a command, we first let domain model process the command and as a result of processing, whenever a state change(insert, update, delete) happens, we store that as an event in an in memory queue. Once the event is fully processed & changes persisted, we publish events, which contain old data, new update , reason for change and reference to command (which is also stored in db). These events can be used by multiple applications.
    Some of the uses we have planned are
    1. Create a distributed cache which will act as read servers. Hence, like you mentioned, we have separated our update db from the read with almost negligible latency between the two via publishing events which get consumed by distributed cache. All reads happen against in memory distributed cache.
    2. Other applications are interested in changes to our model. Hence when a change happens, they subscribe to the events and act on them as compared to doing it offline via batch process.

    • pveentjer says:

      Sounds like you know what you are doing 🙂

      And what are you going to use for the distributed cache?

      • Maninder says:

        We are actually considering 2 options. The first option changes the above architecture. In this option, terracota can be used as L2 cache and it will transparently manage the distribution aspect of the cache. Hence, we do not need a handler to keep a distributed cache current. We will still expose events, but mainly for other systems, which need them. I dont have much understanding of teracotta works, and it is a different group which is evaluating the option, but the premise is that we can hopefully use teracotta as write-through and teracotta will keep our domain model in memory and achieve the following
        1. Sync changes from its memory to db
        2. Provide us with coherent distributed cache, not just for current transactions, but also say 30 days worth of data in memory.
        3. Keep domain model in memory
        Hence from an application perspective, we will deal with (at least in theory) in-memory speeds, and let teracotta manage plumbing. Also in this scenario we do not need to partition our servers between read and write db, because reads are not happening against db schema or physical db, but against in memory cache which contains our domain model. The litmus test will be if we are able to meet our read sla.
        Option 2 as i described above and we will probably go for open source like jboss cache.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: