Me and my family spent our holidays camping in France. A swimming pool for the kids, a glass of wine with a good read for me. With no internet or everyday programming hassles around it was a good occasion to take a step back and read two great books on enterprise application development. Such a subject may sound high-brow but every software application which deals with administrating and persisting data, from an electronic rolodex of your private book collection up to Amazon.com, is an enterprise application. It's the kind of software, not the number of people using it or the amount of data it handles.
The first book is the bible on the subject: Patterns of Enterprise Application Architecture by Martin Fowler; usually referred to as PoEAA. I have to admit I had never read that front to back yet. The second part of the book treats in detail patterns like ActiveRecord, Service Facade, and all the others which come by in you daily blog-reading. That's not something to read front-to-back but it makes a lovely holiday pasture: read through a pattern, read through a related one and then take a swim to let some details sink in. The first part of the book is the narrative part and makes a good evening read. In a couple of chapters aspects of application architecture like layering, the database, presentation and distribution strategies are discussed.
The book was first published in 2002. In those days .NET had just appeared on the scenes and still had to prove itself. Nevertheless .NET gets a lot of attention. Patterns on itself are independent of a programming language, the code examples are in Java an C#. Patterns are not independent of frameworks. Working your way through there are a lot of places where you will recognize the .NET framework and architecture as implementations of the patterns discussed. This on itself makes the book a must read for everyone working with .NET. To see how the parts of the framework can cooperate and to place what you're doing in a wider perspective.
Besides good content a pleasant read requires a good style of writing. When it comes to that PoEAA shines. Without sacrificing anything on the detail the language is very clear and easy to read. Nothing is presented as an absolute truth; the way to architect applications is something in constant flux. The text is rich in references; not just to patterns but also to publications of other authors. The publisher, Addison-Wesley, puts these references in-line, right on the spot where they belong. This is a practice common to scientific publications, not found in software books of many other publishers. I'm very happy with that as it puts the material presented in a discussion framework which is easy to track for the reader.
My second book was Applying Domiain-Driven Design and Patterns by Jimmy Nilsson. Its links with PoEAA start on the cover. Both books carry the picture of a bridge. (A holiday link is that Jimmy's bridge is the one from Denmark to Sweden which we traversed last year's holiday..) The book covers applying one of the main patterns of PoEAA, the domain model. Doing that Jimmy meets a lot (but not all) of the patterns in PoEAA. Fellow CB-blogger David already published a review in his blog describing a lot of details on the content. Here I will just my comments on the experience as a (holiday) read.
In contrast to Martin's book Jimmy's book is quite pragmatic. Starting bottom-up he takes an agile test-driven approach in realizing an application. Agile or TDD are not mentioned anywhere in the (sub-) title but it is one of the most practical introductions to the subject I've read so far. Jimmy also makes quite clear why TDD is important: refactoring the code over and over again leads step by step to a full implementation of the desired functionality. To make sure the app keeps running you just need lots and lots of test. This is a mantra you'll read everywhere but the story in this book makes it obvious from a real-life point of view. Here agile and TDD are taken for granted as the usual way to build an application, no need to do any shouting about that.
Also this book is full of inline links. Jimmy goes even further than that as he explicitly uses reviewer's comments as a alternative way to look at the problem. Quite often fellow CB-blogger Greg comes by. The list of people who have contributed to the book is enormous. The style of the contributions varies. Which works very well in the appendix. In this chapter three guest authors write on another Domain Model Style. There is a SOA approach by Mats Helander, a Database Model approach focusing on entities by Frans Bouma and a Pragmatic approach by Ingemar Lundberg. The first one makes you realize you can't live without visions into the future, the second one you can't live without theory and the third makes you realize that in the end you're just mortal and will do things your own idiosyncratic way.
There is one chapter which gave me mixed feelings. Focus on the UI has three parts, written by three guest authors. The first one, by Christoffer Skjoldborg, discusses the Model View Controller pattern. It focuses on testability on the UI but ends with the remark that it's perhaps somewhat overdone to unit test that. Somewhere in between a remark is made that bindable domain objects could save you loads of work. I'll come back on that. The second part, by Ingemar Lundberg, is (I'm sorry to say this) imho not good. It is called Test-Driving a Web Form, tries to oppose to Model View Presenter Pattern to MVC, makes some sidesteps which are off-topic and in the end I was only confused. Thank goodness the third part of the chapter is marvelous. Mats Helander deals with adding a very simple presentation layer to the application to wrap or map the domain objects. Alas there is no suggestion to make such a presentation object bindable. But with .NET 2.0 that's no big deal.
The style of writing of the book is quite different from PoEAA. Jimmy and all his friends talk you through the problems in a very casual, pleasant and (for most of the co-authors) easy to understand way. The two books are good companions. One as a theoretical background and one a practical guideline. And both to realize that there are no silver bullets and you still need to know what you are doing. It's the man not the pattern.