When you are dropped by parachute deep behind enemy lines with nothing but your analytical skills – where do you start? Ok, I probably should not compare the client and their business with hostile territory filled with enemies. Sorry! But still! Where do you start if you know nothing?

You say “Hi!” to everyone, exercise your complete toolbox of people skills, follow everyone to lunch, buy the informal leaders beer etc… But that is not enough is it?

Being a developer using ECO and the strategies proposed by DDD I will know what to do once I know what “the whole thing is about”. But the client is not really equipped to tell me what I need to know spontaneously, so I need some strategy to get that information extracted from them.

This post is about that strategy. Ok, I know there must be like a million ideas on how this is done. This is the way we do it:

1. Gather a representative group of people from the domain
2. Set up a workshop and let them brainstorm on who is showing any interest at all in what they do. More specifically ask them: who calls you on the phone, who emails you,  who comes to visit, who delivers stuff, who sends you stuff, who buys your stuff, etc. All these questions are reversible: Who do you call, Who do you email etc. Collect this information and keep it as the Triggers.
3. For each unique persona from step 2 find out what the goal of this persona is; why does X email you, what is their goal? Why do you email that person, what is your goal? Collect this information and keep it as the Goals.
4. Split your group into smaller groups and let them break down each non-nonsense combination of trigger and goal into some steps that are central in getting to the goal. Make them aim for 5 steps. If they have a hard time getting started, encourage them to bring up just 1 step. Example: “Trigger is Customer, Goal is Getting a loaf of bread”. One obvious step is “handing the bread to the customer”. Great! Now force your group to explain what they do before- , and what they do after that step. “Need to fetch the bread from the shelf” is before, and “Receive payment” is after. This is going great! Continue like this, and throw away the silly steps and keep the important steps. What they create here are overviews of what their business is about. Keep this information as Processes.

After you are thru these steps you will have a pretty good idea on what you are up against. You will have a set of high level processes. Document these in AppComplete or ECO:

Some processes that you have already found might be detailing processes for a another process. And some steps in a found process might need detailing in further steps; you should callback your domain group to help you out with that.

By arranging the processes as “detailing” a step, you build up a structure in the Modlr tree:

Do you really need to involve real domain people? Will it not suffice with reading some existing documentation and talking to some IT-guys in the company? No. It will not suffice for 2 major reasons:

1. You do not know what the real issue is – it might be that the current documentation and or the current IT-crew is wrong.
2. You really need to get real people involved so that they feel and know that you are on their side. After all you will be a central player when it comes to change of these peoples working environment. You need to earn trust, you need to communicate, you need to make them involved. If you do not you will have a hell of a time trying to get the real people to understand the greatness of your work once you are done. And then it is all for nothing.

When you have reach this far you need to start on the information model. Create 1 class diagram per process and associate the two:

As you focus on a specific process when creating this class diagram you get a small and readable result:

The Process diagrams indicate that they are associated to class diagrams, and you can click the Icon to jump straight to the class diagram:

Further more the Process tree gives you a good structure of diagrams:

Now you have the big picture on “What it is that happens” from the processes, you get the “What information” view from the class diagrams. All you need now is the detailed business rules that controls this process. Being totally into declarative development, I only consider for short while to actually start to write c# code to catch these. But the state diagrams are better because the documentation gets clearer and maintenance will be cheaper in that form (our point of view). You can associate these to processes as well:

Once you have reached this far you may want to take it yet another step: Declare a viewmodel per process… But I will save ViewModels for another post.

Summing it up

The process tree will give you a navigation of diagrams and artifacts. The processes will make it easier for an outsider to understand the domain. And if you are a group of people where some do client communication with process modeling and some take it further with development you can now share one tool to keep your development efforts collected.

Weather you choose to do everything in your development declarative as we do, or only part of your your work declaratively and the rest by traditional coding is entirely up to you.