MSDN Magazine - February 2009 - (Page 8)

Editor’s NotE Driving Design focus our attention on topics related to best practices in software design. This theme is a personal favorite, because good design practices are ubiquitous across all sub-specialties of software development. We have a compelling lineup, with topics ranging from acceptance testing and IronRuby to presentation patterns in WPF—and even an overview of the “Oslo” platform. The article of greatest interest to me, however, is Dave Laribee’s “An Introduction to Domain-Driven Design.” I have been a subscriber to and practitioner of domain-driven design (DDD) thinking since I read Eric Evans’ book of the same name about four years ago and have grown in this way of thinking with minimal problems. I believe that this has been largely due to the complementary relationship between domain-driven design, the rich domain model pattern, and test-driven development. But when it comes to building software, there is no silver bullet. I watch technologies such as Windows Workflow Foundation (WF) and Windows Communication Foundation (WCF) continue to evolve; I see the continued shift toward service orientation. And I can’t help but wonder whether my staunch adherence to certain practices and heuristics has caused me to recreate a few wheels of my own and subsequently undermine one of the goals of good software design—creating a more maintainable system. Let’s take the insurance problem domain that Dave references in his article. I, too, once worked in this industry and built what I considered to be a rather elegant framework for validating policy configurations and calculating projections known as illustrations. I created my domain model from the outside in using a test-driven approach, mapped my model to a database using a popular object-relational mapper, and projected my model onto multiple presentation layers. As I continued to refactor my domain mod- In this issue of MSDN Magazine, we el, I noticed a couple of things. First, all of the logic (and all of the tests) that I had built began to resemble something I had seen before. And in fact, when I stepped back and looked at my domain model, I realized that I had essentially written my own forwardchaining rules engine. Keeping in mind that the most maintainable code is code that you don’t have to maintain, consider how policy illustrations are calculated. The company’s actual calculation logic was created by actuarial scientists using a functional, generally symbolic language such as APL or Mathematica. This logic was then translated into our object-oriented domain model. As I’m sure you can deduce, a great many bugs found during regression testing were introduced in this translation. In light of my own experience, I wonder what my application would have looked like had I refactored my validation logic into a rules engine and taken a more polyglot-based approach for calculating. Would my application have still been “domain-driven”? Or can DDD philosophy be separated from its more frequent, objectoriented implementations? I’ve been reviewing my old code recently, looking to see where my understanding of DDD principles has been biased by my OO coding skills and then refactoring appropriate pieces of the application to more suitable paradigms. What I’ve concluded thus far is that domain-driven thinking is still an essential part of designing software. (In fact, certain elements of DDD become more meaningful in a multi-paradigm design.) In the end, my experience has been a validation of the fact that the domain must drive the design—even when it challenges what is comfortable for us as developers. This issue: Surupa Biswas, Mike Calligaro, John Gossman, Tim Heuer, Ed Katibah, Gaurav Khanna, Ravi Krishnamurthy, Mike Magruder, Rick Molloy, Dave Murray, Michael Puleio, Bob Schmidt, Don Smith, and Matt Winkler. Thanks To The following MicrosofT Technical experTs for Their help wiTh Visit us at msdn.microsoft.com/magazine. Questions, comments, or suggestions for MSDN Magazine? Send them to the editor: mmeditor@microsoft.com. © 2009 Microsoft Corporation. All rights reserved. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, you are not permitted to reproduce, store, or introduce into a retrieval system MSDN Magazine or any part of MSDN Magazine. If you have purchased or have otherwise properly acquired a copy of MSDN Magazine in paper format, you are permitted to physically transfer this paper copy in unmodified form. Otherwise, you are not permitted to transmit copies of MSDN Magazine (or any part of MSDN Magazine) in any form or by any means without the express written permission of Microsoft Corporation. A listing of Microsoft Corporation trademarks can be found at microsoft.com/library/toolbar/3.0/trademarks/en-us.mspx. Other trademarks or trade names mentioned herein are the property of their respective owners. MSDN Magazine is published by United Business Media LLC. United Business Media LLC is an independent company not affiliated with Microsoft Corporation. Microsoft Corporation is solely responsible for the editorial contents of this magazine. The recommendations and technical guidelines in MSDN Magazine are based on specific environments and configurations. These recommendations or guidelines may not apply to dissimilar configurations. Microsoft Corporation does not make any representation or warranty, express or implied, with respect to any code or other information herein and disclaims any liability whatsoever for any use of such code or other information. MSDN Magazine, MSDN, and Microsoft logos are used by United Business Media under license from owner. 8 msdn magazine http://msdn.microsoft.com/magazine http://microsoft.com/library/toolbar/3.0/trademarks/en-us.mspx

Table of Contents Feed for the Digital Edition of MSDN Magazine - February 2009

MSDN Magazine - February 2009 Contents Toolbox CLR Inside Out Data Points Cutting Edge Patterns In Practice Best Practices .Net Interop "Oslo" Basics Patterns Silverlight Under The Table Foundations Windows With C++ .NET Matters Going Places { End Bracket }

MSDN Magazine - February 2009

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.