MSDN Magazine - February 2009 - (Page 49)

describing a problem and building an elegant, maintainable object-oriented solution. To get the biggest bang for your customer’s buck, you want to be sure to understand the core domain of your application. The core domain is the Bounded Context that brings the most value to applying DDD. In any given enterprise system, there are some areas that are more important than others. The more important areas tend to fall into alignment with the core competencies of the client. It’s rare that a business will be running custom general ledger software. But if that business is in insurance (going with my previous example) and their money-making offering is managing risk pools where liability is spread among all members, then they had better be darned good at rejecting bad risks and identifying trends. Or perhaps you have a client that’s a medical claims processor, and their strategy is to flank their competition on pricing by automating payments to amplify the efforts of their bill payor workforce. Whatever the industry, your employer or client has some edge in the market, and this edge is usually where you find the custom software. That custom software is where you’re likely to find and model the core domain. We can measure our investment in value on another dimension, namely where we invest our intellectual capital in reaching technical excellence. Too many times senior developers are the kind of people who get obsessed with new technologies. A certain amount of this is to be expected—the industry innovates at a relentless pace, and vendors are compelled to frequently release new technology offerings to satisfy their customers’ demands and stay competitive. The challenge, as I see it, is for senior developers to master the fundamental principles and patterns that contribute value to the heart of a system. It’s tempting to get wrapped up in a new framework or platform, but we need to remember the reason vendors produce these things is so we can just trust that they work. Entities have both an identity and a lifecycle. For example, If I want to access a particular customer in my system, I can ask for her by a number. When I complete a trading order, it’s then dead to my system and can go to long-term storage (the historical reporting system). Think of entities as units of behavior rather than as units of data. Try to put your logic in the entities that own them. Most times there’s an entity that should receive some operation you’re trying to add to your model, or a new entity is begging to be created or extracted. In more anemic code, you find a lot of service or manager classes that validate entities from the outside. In general, I much prefer to Think of entities as units of behavior rather than as units of data in your application. do that from within the entity—you get all the benefits associated with the fundamental principle of encapsulation, and you’re making your entities behavioral. Some developers are bothered by having dependencies in their entities. Obviously you need to create associations between the various entities in your system. For example, you might need to obtain a Product entity from the Policy entity so you can determine sensible defaults on the policy. Where people seem to fall down is when you need some outside service to perform behavior intrinsic to an entity. I, for one, am not disturbed by the need to involve other, nonentity classes, and I would try to avoid lifting the central behavior outside of my entity. You should always remember that entities are intrinsically behavioral units. Often that behavior will be implemented as a kind of state machine—when you invoke a command on an entity, it is responsible for changing its internal state—but sometimes it’s necessary for you to obtain additional data or impose side-effects upon the outside world. My preferred technique for accomplishing this is to provide the dependency to the command method: public class Policy { public void Renew(IAuditNotifier notifier) { // do a bunch of internal state-related things, // some validation, etc. // now notify the audit system that there's // a new policy period that needs auditing notifier.ScheduleAuditFor(this); } } A System of Single Responsibilities I’ve mentioned that DDD provides a pattern language for structuring rich domain models. By implementing these patterns, you get a certain level of adherence to the SRP for free, and that’s certainly valuable. The SRP encourages getting at the core purpose of an interface or class. It guides you toward high cohesion—a very good thing, as it makes code easier to discover, reuse, and maintain. DDD identifies certain types of class responsibilities in a core collection of patterns. I’ll cover a few of the more primary ones now, but it’s worth mentioning that there are many patterns described by Eric Evans in the original book ranging from class level to architectural. For introductory purposes, I’ll stay at the class level covering entities, value objects, aggregate roots, domain services, and repositories. Because this is an introduction, I’ll only cover the responsibility of each pattern with one to two code examples or tips each. Entities Have an Identity and a Life msdnmagazine.com An entity is a “thing” in your system. It’s often helpful to think about these in terms of nouns: people, places, and, well, things. The benefit of this approach is that you don’t need an inversion of control (IOC) container to create an entity for you. Another perfectly acceptable approach, in my opinion, would be to use a Service Locator to resolve the IAuditNotifier inside the method. This technique has the benefit of keeping the interface clean, but I find the former strategy tells me a lot more about my dependencies at a higher level. February 2009 49 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.