Domain Driven Design promotes the usage of an Ubiquitous Language, in a line, we should all speak the same language, from developers to domain experts.

So it happened that the project were I am it’s a financial one: FiX messages routing…

There’s always an on boarding time, a learning curve with a new domain…
But here things are slightly more complicated than usual…

The most important object of the system is a Fix Message.

It’s an interesting plain object with around a thousand of fields…

There are nice implementation like the mebeliQuickFix one where there’s some object oriented design… (not a surprise, ThoughtWorks was a big contributor of that project) but since we’re working with legacy code the choice in the current system it’s the Cameron implementation, where the APIs are something like message.setField(109, toSomething) or message.getField(115)!
But that’s not the point of the post.
The first days we built up to improve the current code coverage a nice FixMessageBuilder, to build up for us Cameron Fix messages with speaking names and fluent interfaces, just to understand what we are doing. As you know and as it’s valid for the internet protocol remembering letters and names it’s easier than numbers, right?
So another important thing that Domain Driven Design promotes is talk as much as possible with the client, with the Analysts, and that’s what we did.
And we were talking about OnBehalfOfCompID, ClientID and so on… With the result of being almost misunderstood or having always a reply back like ah, OnBehalfOfCompID, right, you mean 115!
We then moved (Shenmebeli first to be honest) speaking like them, there was no choice, I’m still struggling talking like a calculator. A typical (simplified!) conversation will now look like:
A message with 35=D and 15=AUD or 100=AX should not go to Fidessa.
Is there anything more agile than changing our language to better fit into the customer needs?
It’s all your fault Eric Evans!

More on financial fun soon, since the next step is a Domain Specific Language for playing with these things

My friend Bruno kicked off, silently few weeks ago the Java Essential project.

What is Java Essential?

It’s an open, collaborative book, written in Italian about Java and not only.
It will cover topics like TDD, Object Oriented Design and Domain Driven Design, and all the most current/good/trendy frameworks.
It will be written in Italian, for the Italian Java (not only Java really…) community, written by the communities, in fact various good guys from various different Java User Groups and Organizations will write the content.

I’ve been asked to write the chapter about Domain Driven and since I’m not a good writer I’ve asked to Floyd Marinescu if I can translate his nice Domain Driven Design Quickly, and he agreed.

Depending on how much it will take and on how much time I’ll be able to allocate on this project I’ll translate partially the book for Java Essential or the full book, linking it then on InfoQ.
If there’s one thing that I care about is to spread around the world what we do and how we do it, last year I had in total four speeches in Rome, Turin, Varese and Bologna, since I’m a bit far from Europe now, that’s the best way to continue in that direction

I had a good number of jokes and questions since the announcement of the anti-if campaign.

Do you want to remove all these if? What’s wrong with the ifs?

So, it’s better to clarify something.

First of all it’s not about removing every single if, it’s about having a more flexible, maintainable and readable code.

A long case (or if then else) statement can be difficult to read and follow, maintenance can be painful.

The first category of if to get of rid of, the most immediate it’s the type based if.

There is clear: something is wrong, the responsibility is not where the if is but in the class itself.

So, an example.

On a project (in a Domain Driven Architecture) we had a fairly long “if type then, else if type then, etc…”

The if chain was on different Tasks Types in a workflow engine.

Let’s imagine that the workflow is an engine for a touch-less car wash system.

So you have, for example:

InsertCoinTask
2-StepHeatedPreSoakTask
HighPressureTouchFreeWashTask
Tire&WheelCleanerTask
HighPressureRinseTask and so on.

Every task depends on the completion of a previous one and might need a run time configuration.

So, the code was something like this:

if (task is InsertCoinTask)

{ Configure(task as InsertCoinTask) }

else if (task is StepHeatedPreSoakTask) {

Configure(task as StepHeatedPreSoakTask) }
...
Inside of a class called TaskServiceConfigurator, were for example a Configure method was implemented like:

private Configure(Tire&WheelCleanerTask task)
{
task.TirePosition = touchFreeWashTask.LastCarPosition;
}
The different configure methods inside that class (then private!) were setting previous tasks settings, values and so on.

So, pain points:

- The long if: you can easily forget to configure when adding your task to the workflow to add it there

- Private configuration methods: difficult to test, not only the configuration but also when testing the task itself

- Public setters on the tasks: since each task is configured inside the TaskServiceConfigurator all the setting came from there

Solution to this has been a double dispatch.

We added on the Task Interface a method Configure with the ITaskServiceConfigurator as a parameter, like this:

ITask
{
Configure(ITaskServiceConfigurator configurator)
}

Tire&WheelCleanerTask is an ITask and the Configure implementation might look like:

Configure(ITaskServiceConfigurator configurator)
{
tirePosition = configurator.LastCarPosition;
...
}

The above example probably is too stupid, but the key point is that the LastCarPosition depends on other task (performed or not) it’s really a run-time configuration, a real time dependency between tasks.

I found easier to test the tasks, passing a stubbed configuration and the configuration itself had a definitely better code coverage.

Any better solution to this code redesign is more than welcome.

(Task names are taken from this page: http://www.autec-carwash.com/ :-))

It will be an honor to speech after the key note of Tim Mackinnon at the AgileDay organized by Marco in Bologna, I’ll present how we went from amber to green in four weeks in our last project in London, presenting a speech that Pat and I were setting up for the Xpday in London, but we were fired off cos it was “just” a description of a perfectly aligned agile/XP project, they said(!).

It will be also cool to speech again about Domain Driven Design at the Javaday in Rome, with 700 expected attendees that’s now the biggest Java Gig in Italy, it will be the 3rd refactoring of the slides presented since this summer, more focus on mocking, testing and IOC as well, since in Turin I had a lot of questions about it.

Slides in English coming soon here, after the events.