So, where to begin really. Well, in a word it’s been awesome. I’ve never enjoyed joining a Company as much as ThoughtWorks, and have never enjoyed a project as much as the one I’m working on now.
One of the things I’ve really enjoyed has been the application of Domain Driven Design, and refinement of the ubiquitous language - the language of the domain (and consequently the language that’s used in both model and code). I can’t recommend Eric Evans’ Domain Driven Design book highly enough (despite it’s wordiness) for both high-level conceptual thought-provoking-ness and tips for implementation. Jeff Santini (our Iteration Manager) also remarked that it includes an example of one of the best examples of refactoring in any book (with regards to it’s shipping example) - showing how the code more clearly communicates domain understanding.
I’m over trivialising the first part of the book, but a lot of it’s focus is on the use of language, and aiming to keep the language the same between the domain experts, and developers. Incorporating domain objects in the discussions between developers and domain experts. The aim being that over time a ubiquitous language emerges, and the language of the domain is continuously refactored into the code. Ultimately, developers working on code (legacy or otherwise) can learn about the domain as they go. And through discussions with customers, can apply their changes and wishes more easily.
As the website says:
“the most significant complexity of many applications is not technical. It is in the domain itself, the activity or business of the user. When this domain complexity is not dealt with in the design, it won’t matter that the infrastructural technology is well-conceived. A successful design must systematically deal with this central aspect of the software.”
To this end, the book provides some suggestions on how to organise your domain objects, and encourages the use of the ubiquitous language in the naming of classes, and packages, so that everything becomes a valuable expression of the domain.
For instance, I can think of a previous project in my past role where we never captured the domain language, introduing our own names and inventing objects and then forcing them on customers. The result was that we couldn’t converse without attempting to translate, and that introduced inaccuracies and misplaced assumptions. The result was a messy, confusing and difficult to work with codebase. If we’d have dug a little deeper, and collaborated a little more, perhaps we could have ended up with a better model and more communicative code.
I’m yet to break 2/3rds of the way through the book, so there’s tons of useful stuff still waiting (so I’m told), but even so far I’d say it’s been invaluable in helping me approach this kind of business application.
There’s also some great advice about structuring your code, which I’m going to try and use to help me re-organise some of my pet Rails code. I’ll try and keep some notes and post here with updates on how it goes, see if it looks better and whether others can suggest further refactorings. But I digress!
Overall, the move has been one I’ve been very happy with. There’s no doubt I was nervous about starting, but people couldn’t have made me feel more welcome, and working with the other guys and girls on the team has been thoroughly enjoyable!