Josh was right on his comment on my previous post about DDD in the financial world: we had a new requirement from the client: design a market simulator.

Basically our market simulator is a tool to parse the production logs, inject them into the application and verify that the behaviour of the application is correct. (A commercial tool called VeriFIX does more or less the same job, but we need more flexibility)

It will be used when upgrading to newer releases and when installing a new instance of the Fix Routing Engine. It is end to end black box testing, with some reports to understand if everything is still processed by the Fix engine as it's supposed to be.

From a new joiner on the Fix support team we had the request to show in the reports not the tag values for the processed fix messages but the description and (not a surprise) even a senior developer of the client was asking the same feature.

Looking then to the full picture we are always playing with the same object, the famous Fix message, with his near to 1000 fields but we use friendly tag descriptions on tests and code, tag numbers on the DSL: concise and quicker to understand by the Fix team and finally again tag descriptions for the Fix support team in the test reports.

Every context has its own language, even inside the same division, even in the same domain.

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! :-D

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.

Finally I have some time to write about it! I'm organizing for the second year the Javaday in Turin with the Java User Group Turin Coordinators and a little help from some friends... And we are almost done! The conference will be on the 20th of October. What's the Javaday?

The Javaday is an initiative organized by the Italian Java User Groups, by the community of Java Italian Portal and by the Java Italian Association with the goal to promote the knowledge and the usage of the Java technology. Javaday is an on road gig that touches different Italian cities all along the peninsula, spreading the Java technology also in places usually skipped out by big events. This feature makes the Javaday a qualifying and unique moment: every single stage is a direct communication channel in which the technology, the local institutions, the developers and the companies can meet together in order to know each other, share knowledge, compare each other and understand the new opportunities offered by the Java Platform. The participation to the Javaday is free.

This year we expect more people than the 100 we had last year, we have some very interesting speeches,  the Java User Group Padova talking about their creature, Parancoe, Simone Federici from Java Italian Portal talking about Spring with Terracotta DSO and Alberto Lagna talking about the third generation web services and many more, have a look on the website! I'll recycle my speech about Domain Driven Design that I had this summer at the Essap :-) Organizing a conference it's an incredible experience where the stress is almost well balanced by the final satisfaction. Let's see how it goes this year! A special thanks to Victor Zambrano that designed the Javaday Brochure and the posters, to Mariachiara Martina helping us with the communications and the great Java Italian Community, we all did a great job, driven by passion.

I've just right now published the slides of my two last speeches on slideshare, that site is really nice, simple and wao, web 2.0! For time boxing look here, for importance of being driven have a look here!

First, please do not mock a domain object. Stub it. Thanks. Second, do not write an interface for it. Neither if you want a Null Object implementation. Third do not be obsessed with Null Objects, sometimes they are good, not always. If you end with a if objectInstanceType == ObjectType.NULL in your code perhaps something is wrong in your design, a null object is to avoid that stuff and to give a "null behaviour". Forth. Do not use the ActiveRecord pattern, seriously, you're gonna couple the infrastructure layer with the domain layer. It's not a pattern IMHO, kind of antipattern, try considering a repository. Fifth. For the point one maybe you will like a builder pattern in order to stub objects. Here an example: class PersonBuilder { private string name = "testname"; private int age; public PersonBuilder Name(string value) { name = value; return this; } } public PersonBuilder Age(int value) { age = value; return this; } public Person ToPerson() { return new Person(name, age); } Syntax then is nice, I really like it. Person expected = new PersonBuilder().Age(29).Name("antonio").ToPerson(); and it encourages to write not mutable object like this Person: class Person { private readonly int age; private readonly string name; public Person(string name, int age){…} public int age { get { return age; } } } Looks like I've lost my code formatter... :-(

Back to speech! I am very happy about this, my last one was at Java Conference Last year and it's really time to go present something. I'll talk about the Importance to be Driven at the European School of Agile Praticse, in Varese.

I have a lot of draft posts, I think is time to post some of those.

- Sa cosa stavo pensando? Io stavo pensando una cosa molto triste, cioé che io, anche in una società più decente di questa, mi troverò sempre con una minoranza di persone. Ma non nel senso di quei film dove c'è un uomo e una donna che si odiano, si sbranano su un'isola deserta perché il regista non crede nelle persone. Io credo nelle persone, però non credo nella maggioranza delle persone. Mi sa che mi troverò sempre a mio agio e d'accordo con una minoranza...e quindi...

- Do you know what I am thinking about? I'm thinking about a very sad thing, that is that me, even in a better society that this, I'll always see myself in minority of people. Not in the sense of that kind of films where there are one man and one woman hating each others, they fights against each others in a desert island because the director doesn't trust in people. I believe in people, but I don't believe in the majority of people. I think that I'll find myself at ease on with a minority... and so...

My tentative translation, quoting Nanni Moretti in Caro Diario (Dear Diary) And so... I'll continue to develop with test driven, test first, agile practices, scrum perhaps even behavior driven and domain driven and why not interface driven? The importance is to be driven! But more than this fancy things I'll always search for happiness, fun & learning at work.