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
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.
After at least two years of Hibernate and NHibernate experience I can say that I know what’s going on, I can’t still say that I know very well (N)Hibernate but I wanna share some learnings.
The logger is your best friend:
When sometimes goes wrong, the logger (or at least a profiler) will help you, it’s awesome to play with a database like we play with objects but I have the feeling that sometimes we forget that on a couple of layers below we are doing some good old SQL!
(N)Hibernate is not meant for:
Bulk data manipulations: use sqlBulkCopy in (.net) or upgrade to a version > 3.1.1 on Java Hibernate
Free developers from understanding the database: it’s nice to hide the DB structure but the DB is there, and it’s not OO!
Free developers from understanding (N)Hibernate. I sow many times in developers this approach: entusiasm followed by criticism followed by hate It’s very easy to do simple things and terrible then to fix bugs or understand some stack traces. It’s a great library and it’s not easy to use. A copy of hibernate in action or of nhibernate in action should be always present in a team playing with it.
Let you forget the profiler: as mentioned before it’s the best way to understand the complexity of your queries, it’s easy to end up with a cartesian product result from a query or execute unuseful queries, especially when playing with multiple joins and criteria queries.
Do not generate queries using dynamic strings: queries compilations are cached (similar to query plans), it’s a nice and useful feature, especially talking about performances. Use parameters to allow reuse of query plans.
Lazy loading: if you don’t use lazy loading (default now) you’ll end up having all the DB in Memory, if you use lazy loading you might have the select N+1 problem…
Usage patterns: session per request (good for webpages, opening the session on request start, dispose on request end) Vs the session per conversation, good for rich client application. I’ve the impression that in this second case you loose a lot of the hibernate power…
Bags, lists, sets… : choice is yours but keep in mind that especially in a domain driven design you could have some problems having methods playing with (lazy) collections in the POJO/POCO objects. And the cost of changing from one mapping strategy to a different one can be high.
Optimization: you’ll have performance problems, it’s sure, you’ll have it, I don’t believe in preemptive optimization but an eye on the profiler and one on the integration tests timings could help you to find earlier problems that you’ll see otherwise when it’s too late (i.e. in production!)
Don't Use Wizard Code You Don't Understand Wizards can generate reams of code. Make sure you understand all of it before you incorporate it into your project.
