Today I’m going to review two things at once: The book Domain Driven Design by Eric Evans, and our semester project Quizmaker. They both have a lot in common, so why not combine two reviews in one blog post?
After I started to dive into FLOW3, I began to read the recommended book, Domain Driven Design by Evans. It took me quite a while to finish it, but I made it last week. Yay! And it was well worth it. If you’re interested in object oriented programming, you should read it, too. It’s not focused on any specific language, although it’s obvious that it best fits Java-style like languages (all the examples are in Java, too). The book emphasizes the need to find good solutions and to constantly refine them. Evans even argues that good design can only evolve and can never be achieved before actual code is written. Although most of the book is really interesting, I found the greatest value to be in the part about ubiquotus language, because I could relate to it in my current situation: the semester project Quizmaker. In short, ubiquotus language is all about creating a shared understanding of the problem and the things involved. The ubiquotus language should be used by all team members and even by the client. If some terms are unclear or client and programmer communicate in a different language, these differences should be eliminated.
But let me introduce the project. Our group of six students had the task to create a web-based training which creates a quiz based on a XML-file. The whole Quizmaker is written in ActionScript (making heavy use of the Flex framework). Although the task didn’t sound too complicated in the beginning, we once again discovered that the devil is in the details. For example, providing a good visual feedback when a question is answered can be really tricky. Combine that with some user interaction (events … always good for surprises) and some shortcomings of Flex, and you get a nice mix ;). But, today we finished most of it and now we’re looking forward to see it used by our employer!
Now why is this project actually connected to Domain Driven Design (DDD)?. Well, we didn’t talk about designing it domain-driven, but because I’ve been the developer lead, I tried to bring as much of it in as applicable, as well as to look out for problems mentioned in the book. One of the really obvious things was aforementioned ubiquotus language. For example, at the beginning we simply weren’t talking about the same things. We talked about “the feedback” and “the feedback in the end”. This led to question like: “Which feedback are you talking about now?” And then, after some time, it hit me: We had an abstract question class and a training class (containing all questions of one training) already. Why not talk about “question feedback” and “training feedback”? I proposed that to the group and from then on we never had this problem again. It sounds really really obvious when writing about it, but somehow we didn’t have these clear terms in the beginning. But once we identified the problem, it was easy to come up with a ubiqutuos language in this area, and it helped a lot in our discussions later on.
Another important take-away from DDD was the focus on constant refinement, and I tried to look out for possible breakthroughs. When we started out, we divided our project into 3 groups (so that we could do pair programming in the beginning), each responsible for one part of MVC: Model, View and Controller. It was a good start, enabling us to work on separate functionality, but soon we realized that our design with View and Controller was awkard. It took us a while to realize this, but finally I had a look at how people were solving similar problems to ours. The key was to question the MVC pattern itself, or more specifically the use of a traditional Controller in Flex. This was when I discovered the Code-Behind pattern (which actually is a lot like a Controller, but fits better to Flex), which we implemented then. This made our code a lot simpler, while keeping a clean separation between code and presentation.
All in all, we had a lot of fun during the project (despite some Flex crazyiness), and it was nice to see how lessons learned from the book could be applied quite easily in “real life” :)