Domain Driven in the financial world

19 Apr

Posted by toni as financial, TWBlog, DDD, Agile, Java

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 QuickFix 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 (Shen 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

Permalink 1 Comment Comment on this post

Spiking with spikes: what is a spike?

16 Mar

Posted by toni as OOD, TWBlog, Agile

What is a spike?
That question came out at the second Hong Kong Agile meeting, last Wednesday.
I was surprised, a spike was something in my base knowledge, something obvious.
I think I’ve learned first the world spike in a programming context rather than spike in any other context.
Probably is not so obvious and makes sense to blog about it.

knowledge spikes

My first spike was quite few years ago, on my first medium size Enterprise project.
The aim of the spikes was to understand a current system, from the database layer to the UI.
It was pain, I still remember it. It took me almost a week, asking help many times, it wasn’t an XP project.
At the end of the exercise I was able to understand very well the system, and able to contribute well on the project.
The code produced was checked in. To provide context, knowledge for future joiners in the project. Code that should not run in production.

Basically it was a main class, instantiating all what you need to start up the full system.
I’ve to say that the codebase was definitely well designed, otherwise doing such an exercise cold be very very diffult.

spikes checked-in?

Conrad, while giving his presentation with Tom on Agile techniques stated that there should be no check in of the code, since that code should never go on production.
I disagree on most cases, there’s always a value on the spikes.

The only spikes I would not check in are my personal trials to understand what’s going on, crappy code that I would not show us to anybody, so ugly that it doesn’t deserve the honor to go on the code repository: One shot spikes.

design sets spikes

On my last project with Pat we tried different design sets (also including technology decisions) for a big problem of redesign/refactor we had.
Also in that case we put the code under version control. Why? For future joiners for instance, these was what we tried, the solution that won it’s on the trunk, the failures on a sperate trunk folder, spikes can be a good name right?
I’ll take the same approach also starting a new project. Let’s pretend I’ve to start a new java project, an app with a database layer. You can spike the database access with Hibernate, with Ibatis, with EJBS, etc…
It will help you in estimating future stories, in the understanding on how much the chosen solution is testable.

estimations?

A spike should always be estimated, a fixed amount of time can be allocated during an estimation session.
A spike should always achieve a final goal.

If a spike screw completely the estimation throw it away, something is wrong, probably the design, the technology you’re trying to use is too complex to play with it, don’t insist on.
Throw away but check it in, even if not working, on the spikes trunk! I can’t imagine any better documentation for new joiner to justify, to explain, that’s why we didn’t use EJBs, look at that!
Shall I write tests doing a spike? Why not. If you’re trying to find a design I can’t imagine anything better that some old good TDD, if you’re trying to understand the system you can write a main if you’re not familiar with tests or just some tests. A spike can be made of tests.

more on the web…

Take a look also on the definitions on C2.com.

XP.org has his definition as well.

Permalink 2 Comments Comment on this post

Java Essentials

16 Mar

Posted by toni as OOD, TWBlog, DDD, That's Cool!, Java

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

Permalink No Comments Comment on this post

Qi4j: an implementation of Composite Oriented Programming

24 Feb

Posted by toni as TWBlog, ThoughtWorks, That's Cool!, Java

Many thanks to Dan that pointed out on our internal ML to Qi4J.
Quoting from the home page:

Principles
- Composite Oriented Programming builds on some principles that are not addressed by Object Oriented Programming at all.
- Behavior depends on Context
- Decoupling is a virtue
- Business Rules matters more.
- Classes are dead, long live interfaces.

Are you already worried that they’re using xml to do this?

Qi4j is trying to address the flaws of OOP and introduce Composite Oriented Programming to the world, without introducing new programming languages, or awkward constructs. Heck, we don’t even use any XML.

Definitely interesting.

Permalink 1 Comment Comment on this post