Better software faster

I found the website for the book Better Software Faster a couple of years ago, but somehow lost the URL. Strangely, this book is very hard to find in search results and rarely talked about although it is written by two experts in DDD and is very good.

I ranted about the lack of source code examples in Eric Evans’s book, but there is its perfect companion. In Better Software Faster, the authos apply the theories of domain-driven design to a car rental application, thus allowing readers to see how domain modeling is used in practice.

Domain-Driven Design, the quest for software perfection

I've been reading Domain-Driven Design, by Eric Evans, since August of last year. Reviews, both praises and rants, abound on the net -- as demonstrated by the countless quotations in blogs alone-- so I will not even attempt to do my own.

Why does it take so long to finish if it is so well-written? Simple. The book is a mine of information on domain modelling, basic concepts, methodologies, issues, etc. but contains very few code examples, which are the kind of materials that most programmers seek and rely on when studying technical publications. For a very long time, since I've started, in fact, I've been trying to make sure that I understood DDD concepts as the author meant it. I've formulated various interpretations, analysing every single word to try and find the exact meaning and how best to apply the knowledge. One might even say, it was a quest.

I think it has just ended, if indeed it was one. Today, I've scanned literally hundreds of blog entries, pages, and technical articles to try and map the book contents onto more or less compliant code scattered over the Net. At the end of it, I had to come to the same conclusion that I had known all along, but had refused to admit.

There is no single way to apply Eric Evans's teachings. In other words, the Holy Grail of DDD does not exist.

One is allowed to implement a design derived from a model as he sees fit. The details may vary, but the overall concepts must be respected in order to avoid an anemic domain model -- one that resembles a proper model, but only on the surface, as business logic is contained elsewhere.

While one achieves good models by having clear separations of entities, value objects, services, repositories, etc. one is also free to implement things, such as persistence, in any way they want, provided they adhere to good design patterns. One may also choose how the domain model is used: what, why, how a model is called and by whom. For example, I've spent countless hours trying to find the ultimate technique for saving entities, the recurring question being, should the entity trigger its own persistence or should a client of the model do that? The opinions posted in the blogosphere seem to contradict each other, but of course, each has its own merit. Still, I kept thinking that there could only be ONE TRUE WAY.

My enlightenment today after an n-th reading of the book is: it does not matter. The answer lies in the first and last chapters that suggests methodologies and identify the usage of the UBIQUITOUS language as the most important tool to succeed in DDD. Simply put, standardisation is what matters. Make fundamental implementation decisions and stick with these through the development process. So, going back to my example, the case could be resolved by deciding on having client code ALWAYS triggering the save operation. Similarly, the answer to another question that has been floating around on the way to save aggregates will be used as the standard from now on.

What happened today is that I became aware of my mistake, the worst one that developers could possibly make, that is, being inflexible. Considering software development as science or engineering, it does not sound so strange. These fields provide mathematically proven solutions to problems, so why should programming be any different. But, it does. Programming is also a creative exercise.

This is a defining moment, I can finally appreciate the power of domain-driven design and I now understand the scarcity of examples in the book as the author does not wish to tie us to a single methodogy, but leaves enough room for developers to manoeuvre. The plan, now, is to make up my own examples and standardise the ways I implement my model.

Technorati Tags: Domain-Driven Design

Copy/paste command-line utilities

The use of the mouse pointer to mark and copy text from the Command window in Windows can be quite cumbersome. Out of exasperation, I created the following utilities that are based on pbcopy and pbpaste, available in Mac OS X.

These require the .NET framework as can be seen below. The code compiled with Microsoft .NET Framework 1.1.

clipin.cs

clipout.cs

The code is pretty much self-explanatory and should not require further details. But if you need more information, please let me know.

MSN toobar Suite Beta

Following on Beagle’s discovery yesterday, I wanted to see what there was out there for the Windows crowd. Something that would be more accessible than Beagle to the average Joe.

My search drove me to “Google Desktop Search”:http://desktop.google.com first. I wanted to download and test it, given the hype that it received a few weeks back, then I realised that GDS is mostly a web application, with a backend indexing application running in the system tray. Which did not sound too solid to me.

I then came across the “MSN toolbar Suite Beta”:http://beta.toolbar.msn.com/. According to the feature list, it seeemed to integrate well with Windows and to be a proper desktop application. I promptly downloaded and installed it on my system. Apart from a glitch when the application was launched; for some reason, every single file gets scanned by the anti-virus software as they are open, which made the initial indexing very slow. Luckily, MSN Desktop Search, the search component of the suite, is clever enough to pause or slow down indexing according to the computer’s performance. Once indexing resumed, it was very fast. The search was also instantaneous, listing matching results _ala_ Spotlight, with different filtering options.

The appearance of so many new-wave desktop search tools is interesting. I was just commenting yesterday about how this changes the way we interact with information. Presumably, developers realised the need for this type of tools when they found out how Google was gaining in popularity. In any case, these are very useful for _personal data-mining_ on your computer. For instance, during my tests yesterday, I typed a keyword that returned results for documents and e-mail that I never knew existed.

Desktop search tools could very well revive the industry’s interest in free-form database and AI-driven search tools.

Technorati Tags: , , ,