| Patterns of Enterprise Application Architecture
I saw this book on the desk of a colleague. I had already been thinking of picking it up, so I did. I learned two things from this. One, ownership of a book does not equate to an endorsement. Second, take more time when determining if a book is going to meet the desired goals.
My problem was that I just wasn’t paying attention. I saw Enterprise Architecture in the title and missed the Application in the middle. This is a book on how to build Enterprise Applications, not an Architecture connecting them. However, I had purchased it already from Amazon and I do have projects that build Enterprise Applications on top of ECM, so I decided to read it anyway.
The book is divided into two sections, an overview and a reference. The overview is only about 100 pages with about 400 additional pages outlining the design patterns themselves. The basic problem with this book is that if you aren’t familiar with the patterns, the first 100 pages is hard to read. It isn’t that they are poorly written, but you may find yourself flipping to the reference portion to look up the definition of one pattern, and disrupting the flow of the overall book.
This could have been remedied by describing, briefly, each of the patterns as they are introduced. However, Martin goes through and will sometimes mention several patterns for the first time in the same paragraph. This is a shame as it is just a matter of the approach Martin took to the book and not his writing ability or his understanding of the subject matter.
There is one exception, the chapter on Concurrency. It has a wonderful description of the problems faced in this domain and the patterns that address them. It also happens to be co-written by David Rice. I doubt that this is a coincidence. Luckily for me, this was the topic that I needed the most as I personally hadn’t had to deal with any concurrency issues in a very long time.
Fun game to play while reading the book….identifying patterns that are in the Documentum system.
On the positive side, I feel it will make a useful reference down the road. It is hard to review a reference until you have had a while to actually use it. If I find that I am using it quite a bit, I’ll definitely post and give an update.
And my lessons learned? My colleague had already reached the same conclusion that I had. A potentially good reference book, but not one you just pick up and read through. I should have asked. I am also going back to picking my technology books in actual stores so I can take my time and look at them in more detail.