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 
April 25th, 2008 at 2:24 pm
Bom dia!
Hmmmm. I’m not sure that just because in this case the “client” is the IT department that we start talking like them.
There’s something positive in continuing to push them towards the business domain language, which as you recognise, knows nothing of a field 115 (although some of the business SMEs may have been co-opted into that jargon). Perhaps ask Eric what he might do?
I hope our erstwhile colleague and superb OO designer, Fabio G, is working hard on the Cameron APIs to improve them in this regard!
Adeus,
JoshG
May 12th, 2008 at 5:08 pm
Hi Antonio,
This is a puzzling experience. Long lasting systems tend to become “the domain” especially if you have to deal with the very people that created the system as Domain Expert.
Unfortunately they tend to mix up problems and 20 years old solution in the same pot, so you can’t exactly figure out what the original problem was and why the solution has been designed this way. After 20 years use, the solution IS definitely part of the domain.
I believe that approaching complex domains with learner’s eyes is normally a “plus” because could help followers to help learning a possibly simpler domain model. On the other hand, every IT people has to face the command-line-power-user-myth: the creatures who is so proficient with the old system that needs every new system to completely mimic the old one. I honestly doubt that people that can’t compensate a small change in UI are “incredibly efficient” but I do normally avoid to question that. What I discovered, is that new job market dynamics are making easy-to-learn systems more appealing in companies with a higher turnover. And learning code 115 or XB3 is a waste of time.
The point is that your application ecosystem will be different from the application development ecosystem. What Eric Evans stresses is that you have to put a lot of effort to make the two ecosystems overlap, and maybe talk the same language. This task is not easy at all, and human factor is success factor number one, ’cause your job must not be seen like a treat but like an opportunity instead…
Ciao
Alberto
May 18th, 2008 at 7:40 am
Hey Josh thanks for youe comment,
I remember a nice conversation had with Dan North, it’s also everything about context. So, the DSL with strange numbers is perfect in the context of the IT Department, where QAs, FiX experts are happy with it. On the other hand, in the code, for new team on-boarding, it’s easier to have speaking names and that’s what we have in our tests.
On other levels / departments of the organization our app should just work, no need to understand how and why and it’s should be completely transparent. I’m sure that a trader ignores what’s there, behind the scenes
May 18th, 2008 at 7:48 am
Hi Alberto, I totally agree with your sentence “approaching complex domains with learner’s eyes is normally a “plus” because could help followers to help learning a possibly simpler domain model”.
I think that here is were we are great at, the design we are implementing is much simpler.
If you’re very strong technically or in the domain it’s much difficult to let emerge abstractions, that’s were an agile developer can dramatically improve the quality of a system.
On the other hand without a strong and continuous efficient communication with the domain experts the solution will risk to do not converge the expected one!
June 17th, 2008 at 11:27 am
[…] was right on his comment on my previous post about DDD in the financial world: we had a new requirement from the client: […]