MSDN Magazine - February 2009 - (Page 47)

the minds of domain experts, the desires of stakeholders, and the requirements of industries in which we’re working. These are, in a very real sense, the shadows to Plato’s imaginary cave dwellers. Furthermore, you are often constrained by programming languages and considerations of time and budget in trying to reach that Form. It’s not much of a stretch to say these limitations are the equivalent of cave dwellers only ever being able to see the interior wall of shadows. Good models exhibit a number of attributes independent of their implementation. The fact of the matter is, the mismatch between the model that’s in everyone’s head and the model you’re committing to code is the first thing an aspiring domain modeler should understand. The software you create is not the true model. It is only a manifestation—a shadow, if you will—of the application Form you set out to achieve. Even though it’s an imitation of the perfect solution, you can seek to bring that code closer to the true Form over time. In DDD, this notion is called model-driven design. Your understanding of the model is evolved in your code. Domain-driven designers would rather not bother with reams of documentation or heavy diagramming tools. They seek, instead, to imbue their sense of domain understanding directly into their code. The idea of the code capturing the model is core to DDD. By keeping your software focused on the problem at hand and constrained to solving that problem, you end up with software receptive to new insights and moments of enlightenment. I like what Eric Evans calls it: crunching knowledge into models. When you learn something important about the domain, you’ll know right where to go. The software you create is not the true model. It is only a manifestation of the application Form you set out to achieve. understand everything that will need to go into delivering the supporting software from this abstracted description? User stories, properly done, are an invitation to have a conversation with their author—the user. This means when you go to work on the approve/ deny policy feature, you should ideally have access to an underwriter. Underwriters, for the uninitiated, are domain experts (at least good ones are) who determine whether a certain category of exposure is safe for a carrier to cover. When you begin discussing the feature with your underwriter (or whomever your project domain expert might be), pay especially close attention to the terminology the underwriter uses. These domain experts use company- or industry-standard terminology. In DDD, this vocabulary is called the Ubiquitous Language. As developers, you want to understand this vocabulary and not only use it when speaking with domain experts but also see the same terminology reflected in your code. If the terms “class code” or “rate sets” or “exposure” are frequently used in conversation, I would expect to find corresponding class names in the code. This is a pretty fundamental pattern to DDD. At first blush, the Ubiquitous Language seems like an obvious thing, and chances are a good that number of you are already practicing this intuitively. However, it is critical that developers use the business language in code consciously and as a disciplined rule. Doing so reduces the disconnect between business vocabulary and technological jargon. The how becomes subordinate to the what, and you stay closer to the reason for your job: delivering business value. Context Talk the Talk Let’s examine some of the techniques DDD provides for achieving this goal. A big part of your job as a developer is working with non-coders to understand what you’re meant to deliver. If you’re working in an organization with any kind of process, you likely have requirements expressed as a user story, task, or use case. Whatever kind of requirements or specification you receive, is it usually complete? Typically requirements are somewhat murky or expressed at a high level of understanding. In the course of designing and implementing a solution, it’s beneficial when developers have access to the people who bring some expertise in the intended domain. This is exactly the point of user stories, which are typically expressed according to a template like this: as a [role], I want [feature] so that [benefit]. Let’s take one example from the domain of insurance policy management: as an underwriter, I want approval control over a policy so that I can write safe exposures and reject risky ones. Is there anyone who understands what that means? I know I didn’t when I saw it written and prioritized. How can you possibly msdnmagazine.com Developers are, in a sense, organizers. You sling code (hopefully with intent) into abstractions that solve problems. Tools such as design patterns, layered architectures, and object-oriented principles give a framework for applying order to evermore complicated systems. DDD extends your organizational toolbox and borrows from well-known industry patterns. What I like most about the organizational patterns that DDD lays out is that there are solutions for every level of detail in a system. Bounded Contexts guide you toward thinking of software as a portfolio of models. Modules help you organize a larger single model into smaller chunks. Later, I’ll cover aggregate roots as a technique for organizing small collaborations between a few highly related classes. In most enterprise systems there are course-grained areas of responsibility. DDD calls this top level of organization a Bounded Context. Workers’ compensation insurance policies need to be concerned with elements such as: • Quoting and sales • General policy workflow (renewals, terminations) • Auditing payroll estimation February 2009 47 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.