Hello, Dino Esposito here. A lot has changed since our previous post on Microsoft .NET: Architecting Applications for the Enterprise, Second Edition (NAA4E)—here’s an update. (Please note that #NAA4E is the official hashtag and name of the Facebook page for this book.)
By the way, as we write this post the current edition of the book is still popular in the Microsoft development section of Amazon—this is an amazing result for a book that was publishing in the fall of 2008. At that time the Lehman Brothers bankruptcy and the subsequent worldwide economic crisis (whose effects are still with us) hadn’t happened yet, Facebook was still second to MySpace in the list of largest social networks, Entity Framework v1.0 was still in beta, Silverlight was the dazzling future of web development, and nothing like Nuget or SuperCalifragilisticExpialodiciousJS were around. As you can see, it was quite a different world.
The TOC of NAA4E has been updated during our writing. This one is final:
Part I Foundation
Chapter 1 Architects and architecture today
Chapter 2 Designing for success
Chapter 3 Principles and patterns of object-oriented design
Chapter 4 Writing software of quality
Part II Devising the architecture
Chapter 5 Discovering the domain architecture
Chapter 6 The presentation layer
Chapter 7 The mythical business layer
Part III Supporting architectures
Chapter 8 Introducing domain modeling
Chapter 9 Implementing domain modeling
Chapter 10 Introducing CQRS
Chapter 11 Implementing CQRS
Chapter 12 Introducing event sourcing
Chapter 13 Implementing event-sourcing models
Part IV Layered architecture: Tail
Chapter 14 The persistence layer
Chapter 15 Cross-cutting concerns and technologies
The biggest change is the introduction of Chapter 5, “Discovering the domain architecture.” We received insightful feedback from our excellent tech reviewers, and that feedback firmed up an abstract thought that was already floating around in our minds. Too often domain-driven design (DDD) is mistaken for just having an object model with some specific characteristics in its implementation. But is this the real sense of an approach called domain-driven design? Read that again: design of some software driven by the business domain to which it belongs. And that’s what we did in Chapter 5—we sought and let emerge the true nature of DDD that Eric Evans attempted to describe in his blue book a decade ago. Take a look at this from Eric for a more modern perspective on DDD: http://qconlondon.com/london-2009/presentation/What+I%27ve+learned+about+DDD+since+the+book. In the development of our book, we discovered a more comprehensive view of DDD and the ROI of ubiquitous language and bounded context. This has little to do with specific software techniques like building a domain model. And all of a sudden that clarified the role of CQRS and event sourcing.
Finally, we’ve added a lot about polyglot persistence and we’ve added from-the-trenches views of software scalability and usability via real case-studies. We also started writing a sample application, an online store called I-Buy-Stuff. We plan to release and update its source code in three flavors using Domain Model, CQRS, and Event Sourcing as supporting architectures on CodePlex nearly at the same time the printed book is available.
We’re publishing this summer—we’re almost there! Thank you for your interest!