MSDN Magazine - February 2009 - (Page 48)

Quoting Creates New Policies Core Policy Work ow Schedules Audits Endorses Policies, Closes Periods Auditing Billing Generates Billing Schedules Figure 1 From Bounded Context to Context Map • Quarterly self-estimates • Setting and managing rates • Issuing commissions to agencies and brokers • Billing customers • General accounting • Determining acceptable exposures (underwriting) Wow. That’s a lot of stuff! You could incorporate all of this into a single, monolithic system, but doing so leads you down a foggy, amorphous path. People are talking about two entirely different things when they chat about a policy in the context of a general workflow versus a policy in the context of payroll auditing. If you use the same policy class, you’re fattening the profile of that class and getting a long way from tried-and-true best practices such as the Single Responsibility Principle (SRP). Systems that fail to isolate and insulate Bounded Contexts often slip into an architectural style (amusingly) called The Big Ball of Mud. In 1999, Brian Foot and Joseph Yoder defined the architectural style (or anti-architectural style, as the case may be) in their classic paper of the same name (laputan.org/mud). DDD nudges you toward identifying contexts and constraining your modeling effort within particular contexts. You can use a simple diagram, called a context map, to explore the boundaries of our system. I’ve enumerated the contexts involved in a fully featured, insurance policy management system, and Figure 1 takes this from a textual description to a (partial) graphical context map. Did you notice some key relationships among the various Bounded Contexts? This is valuable intelligence because you can start making informed business and architectural decisions such as packaging and deployment design; choice of technology used to marshal messages between models; and, perhaps most important, where you choose to set milestones and deploy effort, time, and talent. One last but very important thought about Bounded Contexts: each context owns its own Ubiquitous Language. It’s important to differentiate between the notion of a policy in the auditing subsystem versus the policy in core workflow because they’re different things. While they may have the same identity, the value objects and child entities (more on these in a bit) are often radically different. 48 msdn magazine Since you’re modeling within context, you also want the language to provide precision within that context so you can have productive communication with domain experts and within your teams. Some areas inside models group more closely together than others. Modules are a means of organizing these groups within a particular context, serving as mini-boundaries where you want to stop and think about associations to other modules. They are also another organization technique that leads you away from “Small Balls of Mud.” Technologically, modules are easy to create; in the Microsoft .NET Framework they are simply namespaces. But the art of identifying modules involves spending a little time with your code. Eventually you may see a few things emerge as a mini-model within a model, at which time you may consider dividing things into namespaces. Teasing apart models into cohesive modules has a nice effect in your IDE. Namely, since you need to use multiple using statements to include modules explicitly, you get a much cleaner IntelliSense experience. They also give you a way of looking at associations between larger conceptual chunks of your system with a static analysis tool such as NDepend. Introducing an organizational change to your model should prompt you to engage in some pragmatic, cost-benefit thinking. When you use modules (or namespaces) to divide up your model, you really want to question whether you’re dealing with a separate context. The cost of cleaving out another context is usually much higher: now you have two models, likely in two assemblies, that you need to connect with application services, controllers, and so on. Know Your Value Proposition Most development shops have a handful of both seasoned businesspeople and top developers who are capable of isolating and cutting contexts by architectural Need Bounded contexts needn’t be organized solely by the functional area of an application. They’re very useful in dividing a system to achieve desired architectural examples. The classic example of this approach is an application that has both a robust transactional footprint and a portfolio of reports. It’s often desirable in such circumstances (which might occur pretty often) to break out the reporting database from the transactional database. You want the freedom to pursue the right degree of normalization for developing reliable reports, and you want to use an Object-Relational Mapper so that you can keep coding transactional business logic in the object-oriented paradigm. You can use a technology such as Microsoft Message Queue (MSMQ) to publish data updates coming from the model and incorporate them into data warehouses optimized for reporting and analysis purposes. This might come as a shock to some, but it’s possible for database administrators and developers to get along. Bounded Contexts give you a glimpse of this promised land. If you’re interested in architectural Bounded Contexts, I highly recommend keeping tabs on Greg Young’s blog (codebetter.com/blogs/gregyoung). He’s quite experienced with and articulate about this approach and produces a fair amount of content on the subject. Domain-Driven Design http://www.laputan.org/mud http://www.codebetter.com/blogs/gregyoung

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.