Designing OO-systems with DDD

Digging through Domain Driven Design (Eric Evans, Addison-Wesley) I've come to think about what impact DDD (not just necessarily DDD, but that's the hype right now) has on the design and implementation of a system using object oriented languages.

One of the biggest problems I have with peoples code (including my own)is that it's almost always not as OO-ish as it could and should have been. I'm quite sure that the reason for this is that the code that I work with is written by people coming from non-OO languages/environments. Some come from PHP/ColdFusion/webish/scripting and others come from VB/ASP/VBScript/Microsoftish.

My perception is that these people mostly get the point of encapsulation quite fast, at first using classes as a construct to group related functions (not behaviour) eg; StringHelper.DoStuff, ArrayHelper.Join, etc. Sometimes only using statics or sometimes using instance methods, although the object itself has no state.

Later they find out that it's quite useful to have state although mostly their class still contains utility methods. To given an example in DotNet, the class contains a getter and setter for a DataSet and the methods in the class operates on that DataSet. Persistence is usually handled by some other class using something like:
user.SetPassword("new");
x.y.z.DataAccess.UserManager.Save(user.DataSet);

Sometimes the code is structured as:
LogicLayer.User.ChangePassword("old", "new");
DataLayer.User.Save(LogicLayer.User);

A tiny bit better than the first one, if you ask me.

And that's where it usually stops. Unless the person is constantly reading books/papers/articles about new techniques/architectures/etc and other peoples code. My impression is that most developers don't.

For a couple of years now I've gradually tried to explain to people around me (again, including myself) that they should try to model the "real world", the domain, the logical view, the clients view or watever you'd like to call it. In the beginning I really had no good way of explaining this and how it differs from the other ways (some of them mentioned above) and more importantly how it affects the result. Then I read Agile Software Development (Robert C. Martin, Prentice Hall) and started recommending that, now I'd have to say DDD instead or maybe, depending on the persons level of undestanding for/in OO, first ASD and then DDD.

Prefixing interface names with I

I don't like it. I don't do it, unless I'm forced to (by ruling conventions or by customer/project "guidelines").

Worth mentioning; since I came to DotNet from Java, where it's not done, I'm used to not doing it.

But since it's standard in the DotNet framework and de-facto standard in DotNet projects I've thought about it from time to time, as well as discussed it with my colleagues.

My current on this issue is:
I don't think it's the way to go. Because;
a) It reveals to the client that it's using an interface, the client shouldn't care.
b) If the interface is removed (due to refactoring) and replaced with a concrete class, the typename change and all references has to change.
c) If a concrete class is abstracted (due to refactoring) and replaced with an interface, the typename changes and all references has to change.

Therefore; I don't think that interface names should be prefixed or suffixed with anything. If it's really important to the client to know whether it's using an interface or a concrete class it can always find out by browsing the source or using reflection...

The System

For the last four years I've worked on an information handling system (The System) for my self. A system to categorize, sort and index all my digital resources (my PDF documents, that nifty word template, plain text code snippets etc). The domain model (DM) for the system has been complete and feature frozen for the last three years but the implementation approach and technical platform has changed numerous times.

I've actually had three proof of concept implementations for the domain model up and running:
v0.1 (early fall of 2001) Unix file system implementation + Apache with directory browsing as the interface
v0.2 (winter of 2001) Logic in PHP, storage in LDAP
v0.3 (fall of 2002) Logic in Java, storage in LDAP with new schema

The current version is implemented in Java, using Hibernate to persist the model to an RDBMS, the basic find, add, remove, edit functionality is in place but since I'm now half way through DDD I've started to reconsider if some of my Value Objects are actually Entities and vice versa as well as whether my aggregates are "correct" for my DM. This illustrates the fundamental problem and the, relatively short, lifecycle of each implementation.
Come up with a cool implementation technique
Throw the basic model and logic together with some unit tests
Start hacking on a UI (so far it's been web and/or Swing), velocity decreases (UI is booring)
Find a new cool book/pattern/technique/implementation approach
Terminate, archive solution and start over using/applying whatever was discovered in step 4
The worst part is that I'm actually quite comfortable with this even though I curse myself since the darn thing's never going to be finished. And I do need the system. The worst possible scenario would be that someone else (Microsoft would be über worst) comes up with a complete and working system so that I'd have to permanently discontinue my work in this area. Especially since they seem to have a wire tap on my brain considering their recent release of libCheck. I actually (belive it or not) prototyped a tool like that in the fall of 2003 although my implementation was a bit more rough. My thought was to implement an (n)Ant task used to bump the version number if the public API had changed.

Well easter holiday is knocking at the door, maybe I'll be able to get my shit together and do some work on The System during the next few days. Now I'm going to check in todays work and then I'm off to hold a (technical) recruitment interview.

VeryBizarre.Net

So, for the first time I'm knee deep in VB6 and VB.Net amongst others (lots of everything on my current project) and anxiously awaiting my copy of Working Effectively with Legacy Code (Michael Feathers, Addison Wesley).

Fixed a possible null reference access yesterday by changing:
If connection.State = ConnectionState.Open Then
connection.Close()
End If

to:
If Not connection Is Nothing And connection.State = ConnectionState.Open Then
connection.Close()
End If

At least I thought so, shows up that the And-operator in VB isn't short circuit...enter AndAlso:
If Not connection Is Nothing AndAlso connection.State = ConnectionState.Open Then
connection.Close()
End If

My next thought: "How do you do short circuit Or?" *drumroll* OrElse, but of course...what else...

Spend a few seconds Googling the history of this nasty language and found http://weblogs.asp.net/dneimke/archive/2003/08/13/23844.aspx, read it, had a laugh and showed it to my colleague whose immediate response to "TryHarder" is "How about CatchMeIfYouCan?".