Tag Archives: DDD

Events and Generic Formats

There was some interesting discussion before I left for Nepal about Event Stores. The general question is “can you have a generic event log similar to a transaction log in a database”. A related question is what is the difference between an event log and a transaction log.

Having an event log is not a new idea, its been around for decades. Databases due something very similar inside of their own transaction log. The major difference between an event log and a transaction log is that by definition an event log also captures intent. Consider the difference between:

INSERT:
RecordType: Customer
Id: 17
Name: Greg
Status: Normal

and

CustomerCreated:
Id: 17
Name: Greg
Status: Normal

There are many semantic and linguistic differences between these two concepts. The first would be a transaction log and the second an event log. With a create these differences can be very subtle. Let’s try something less subtle.

UPDATE:
RecordType: Customer
Status: Gold
Id: 17

CustomerAutomaticallyPromotedToGoldStatus
Id: 17

Here intent is quite obviously different between the two messages. There could be a second event CustomerManuallyOverridenToGoldStatus which represents a manual override of our algorithm for dealing with customer promotions. A subscriber may care *why* the customer was promoted. This concept of intent (or “why”) is being represented in the event log.

As an important concept. If you can have two events use the same transition then you are by losing information

Things get to be a bit harry though and this is where the discussion started falling apart. I wish I could have dropped in a longer response but was travelling at the time. Can’t we model the first to be equivalent to the second? We see something in RESTful APIs.

UPDATE:
RecordType: Customer
Action: AutomaticPromotion
Id: 17

YES you can do this! This produces a record that captures the intent as well. In fact this is how my second event store worked. There are lots of reasons you may want to do this (such as ability to use a generic state box on top in certain HA scenarios with the event store).

We can just consider this a different serialization mechanism. The key is that everything still maps directly back to a single event.

Now let’s get back to that original question of “event log vs transaction log”. An event log includes business level intent, this is not needed with a transaction log. An event log is a stricter definition of a transaction log. I don’t need to store the intent in order to be a transaction log though we can have a really interesting discussion about what the “business events” are in a database domain :).

Is an Event Log a type of journal or transaction log? Yes. I like to think though that even if you use the generic update as in the third example above it requires that you specify intent. Intent is a valuable thing. Can I build a transaction log that completely captures intent and does not lose information? Sure think about a database with a “Transaction” table. I would say this is actually just a serialization mechanism with the intent of being an event log.

If I don’t store intent there are an entire series of questions I can no longer ask the data.

Powerful Questions

Powerful questions are key to good analysis sessions.

From http://www.theworldcafe.com/pdfs/aopq.pdf a great quick read btw.

“Questions can be like a lever you
use to pry open the stuck lid on a
paint can. . . . If we have a short
lever, we can only just crack open
the lid on the can. But if we have a
longer lever, or a more dynamic
question, we can open that can up
much wider and really stir things
up. . . . If the right question is
applied, and it digs deep enough,
then we can stir up all the
creative solutions.”

Powerful questions dig into underlying assumptions, they create interest, and most of all they get people interested and good discussions come forth from them.

Question why

I am looking for what powerful questions you use in your analysis process so we can create a list (grabbing some from an old thread in my email as well). Here are some examples:

What is the smallest possible thing we can do to deliver this business value?

What is the need this system fills, not “what it does”

If I turned off the server tomorrow who would be the first person to notice and why?

How would you verify that this is working correctly?

what is the earliest point you can know whether the system has any value to you? How will we do this?

Why are we starting here?

Please keep them coming, the idea of powerful questions can quickly unlock the door to great discussions involving our software process.

The Context Game

After the last post The Gibberish Game, I figured I would drop in some more posts about analysis games as they can be fun (as well as quite valuable in getting information about a domain out of people.

Many times people have a very hard time with understanding that they do have contexts in their organization. This game shows different context and can be used both as an analysis game or more for a business side workshop (more on that later).

Context

The Context Game

Take a team of developers and a group of business people from different sections of the company (developers are familiar with “asking questions” etc). Break apart the group into sub-groups of one (sometimes more) business person and a developer. The groups should be grouped based on business function (this is very important, we will see why later).

Have the groups break apart into different places (a time boxed session). Give them a loaded word from the problem domain. In an insurance domain you might pick the word “policy” other good words might be “customer”, “student”, “goal”, “campaign” to name a list of some I have used previously.

The role of the developer is to capture information in this game not to get into discussions bringing about common understanding. Capture a definition of what the term means to the expert. If the term is something tangible, it can be fun to also draw a picture during the time that you are separated.

Get the group back together and have each of the teams present their idea of what the term means (and hang their picture on the wall if they have one).

Likely you will get drastically different points of view over what a term actually means. This is completely normal. Some questions to ask the group might be “How do we communicate when we all have such different definitions of a common word, have we ever played the telephone game? Can you remember any situations where communication issues have come up because of different definitions?”. Continuing questions might include seeing if anyone has different words to describe any of the other view points, e.g.: “Sales called it a Policy, Claims calls it an Origination for them a Policy has this further definition …”.

This game can very quickly show you context differences within the organization. This game can also be used as a business exercise with the choosing of a very loaded term like “Ideal Customer”. It can show the different points of view of members of the meeting allowing others to understand where people are coming from.

The game is best used when you feel that you have multiple contexts being discussed at once inside of a problem. It can quickly identify the different contexts and make them very apparent to the individuals involved. The drawing of the item if possible helps with memory retention of the concepts (visualization), it also helps with making the workshop a bit more fun.

The Gibberish Game

I figured I would drop up a quick post on a game I like to play with domain experts. Very often when getting into a context or discovering new concepts we have a tendency to just take the first word that comes to mind.

This is quite an unfortunate scenario though as often the word really sucks. What is worse is that often the word carries mental baggage with it because it is used in another context or has some definitional qualities that carry more or less information than you want to be using in the context that is being discussed. In other words

Selecting an existing word early in the process shapes our thinking.

We as creatures are easily biased. So here is the game:

Holy gibberish

The Gibberish Game

Refuse to allow a real word to be given. When going through use cases etc make a word up out of some sounds and use that for the first few hours of discussion.

Once you have gone through some analysis. Revisit and try defining the words more specifically.

Replace the word with a real word. You will be amazed how often it is different than the one you would have first selected.

The goal of the game is choosing different words until we have far more information. This can help eliminate some cognitive bias. This game can be quite good for getting confusing discussions laser focused especially when you are stuck on “what should we call this thing”

be careful you can’t use the same make believe words over and over again either otherwise they gain baggage themselves.

I played this game with a client this fall. We chose toglies and glotys to describe some concepts. When we felt that the conversation was using too broad words. Sure enough at the end we had different words. The game can be fun too (try recording yourself talking about the marital patterns of toglies).

I didn’t make sure to check up with them to share this but I can’t imagine how toglys and glotys could be covered under a NDA :) btw doesn’t gloty sound like something you would order in a Polish restaurant?

We don’t need to always be so serious, even if we are wearing suits.

Sculptor “DDD” Toolkit

Just had someone send me a link to this.

Seems like another MDA “DDD” tool.

Whats wrong with this picture?

Screen Shot 2012 02 28 at 7 07 37 AM

These sentences?

“Within 15 minutes you can go from scratch to a running application, including build scripts, Eclipse projects, domain model, JPA persistence, services, Web Flow application and much more. Thereafter you can continue by evolving the design, add manual code and regenerate.”

Then I saw:
“Say Hello – Entity, Repository and Service are some of the available building blocks. Yes, it is real DDD-style.”

Here’s the link *WARNING NOT SAFE TO BE DRINKING COFFEE AS IT MAY COME OUT OF YOUR NOSE WHEN WATCHING* http://fornax-sculptor.blogspot.com/2009/08/introduction-to-sculptor.html

I imagine its probably better than that but I hate marketing BS.

Follow

Get every new post delivered to your Inbox.

Join 7,602 other followers