MSDN Magazine - February 2009 - (Page 53)

anti-corruption Layers an anti-corruption Layer (ACL) is another DDD pattern that encourages you to create gatekeepers that work to prevent nondomain concepts from leaking into your model. They keep the model clean. At their heart, repositories are actually a type of ACL. They keep SQL or object-relational mapping (ORM) constructs outside of your model. ACLs are a great technique for introducing what Michael Feathers calls, in his book Working Effectively With Legacy Code, a seam. A seam is an area where you can start to cleave off some legacy code and begin to introduce changes.Finding seams, along with isolating your core domain, can be extremely valuable when using DDD techniques to refactor and tighten the highest value parts of your code. to derive a base repository interface from the previous example is a simple matter: public interface IRepository where T : IEntity { Find (int id); Find (Query query); Save(T entity); Delete(T entity); } relationship diagrams (ERDs) or entity-relationship models and class diagrams break down. You need to see the application’s parts in motion and how types collaborate to get work done. When I am modeling, I often reach for sequence diagrams on a whiteboard as a communications tool. This approach captures much of the essence of communicating a behavioral design or problem without the ceremony of Unified Modeling Language (UML) or model-driven architecture. I like to avoid unnecessary ceremony, especially when I’m going to erase the diagrams I put on the whiteboard. I don’t worry about 100% UML adherence in my diagrams, preferring simple boxes, arrows, and swim lanes that I can sketch quickly. If you don’t already use sequence diagrams on your team, I highly recommend learning the technique. I’ve observed the powerful effect they have on getting team members to think through issues around the SRP, layered architecture, behavior design over data modeling, and architectural thinking in general. Becoming proficient with object-oriented programming is no trivial undertaking. I believe competence is within the reach of most professional developers, but it takes dedication, book learning, and practice, practice, and more practice. It also helps if you adopt an attitude of craftsmanship and continual learning. How do you get started? Simply put: do your homework. Learn about things like the S.O.L.I.D. principles (butunclebob.com/ArticleS. UncleBob.PrinciplesOfOod) and study Eric Evans’ book. Your time investment will more than make up for itself. InfoQ has produced a smaller version of the DDD book that introduces a few key concepts. If you’re on a financial or temporal budget or simply in investigation mode, I recommend starting there. Once you get a solid footing, wander over to the Yahoo! DDD group (tech.groups.yahoo.com/ group/domaindrivendesign) to see what issues your fellow designers are struggling with and get involved in the conversation. DDD is not a new doctrine or methodology. It’s a collection of time-tested strategies. When you get ready to practice, try adapting those philosophies, techniques, and patterns that make the most sense in your situation. Some elements of DDD apply more universally than others. Understanding the reason for your core domain’s existence by uncovering and using the Ubiquitous Language and identifying the contexts in which we’re modeling are way more important than nailing that perfectly opaque and onesize-fits-all repository. When you’re designing your solutions, design for value. If designers produce art and developers are a kind of designer, then our medium has to be business value. Value consciousness trumps considerations such as adherence to dogma and choice of persistence technology, as important as these choices sometimes seem.  Getting Started with DDD Repositories prevent database or persistence concepts, such as SQL statements or stored procedures, from commingling with your model and distracting you from the mission at hand: capturing the domain. This separation of model code from infrastructure is a good attribute. See the sidebar “Anti-Corruption Layers” for a more detailed discussion. At this point, you have likely noticed that I am not talking about how aggregate roots, their subordinate entities, and the attached value objects actually get persisted to disk. This is intentional. Saving the data required to perform behavior in your model is a concern orthogonal to the model itself. Persistence is infrastructure. A survey of these technologies is far beyond the scope of an introduction to DDD. Suffice it to say there are a number of suitable and mature options for storing your model’s data from Object-Relational Mapping (ORM) frameworks to document-oriented databases to “roll-your-own” data mappers for simple scenarios. The Thing with Databases By this point, I’m sure you’ve thought, “This is all well and good, Dave. But where do I save my entities?” Yes, you have to deal with this important detail, but how or where you persist your models is mostly tangential to an overview of DDD. A number of developers or database admins will make the assertion that the database is the model. In a lot of cases, that’s partially true. Databases, when highly normalized and visualized with a diagramming tool, can convey a lot about the information and relationships in your domain. Data modeling as a primary technique leaves something to be desired, however. When you want to understand the behaviors inherent in the same domain, data-only techniques such as entitymsdnmagazine.com Dave Laribee coaches the product development team at VersionOne. He is a frequent speaker at local and national developer events and was awarded a Microsoft Architecture MVP for 2007 and 2008. He writes on the CodeBetter blog network at thebeelog.com. February 2009 53 http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod http://tech.groups.yahoo.com/group/domaindrivendesign http://tech.groups.yahoo.com/group/domaindrivendesign http://www.thebeelog.com http://www.msdnmagazine.com

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.