We give you a gentle introduction to designing and evolving rich domain models as part of integrating Domain-Driven Design (DDD) into your coding efforts.
MSDN Magazine February 2009
View Complete Post
Jeremy Miller explains how internal Domain Specific Languages can help you craft code that is easier to read and write. His bag of tricks to improve your programming includes extension methods, fluent interfaces, object extensions and use of the semantic model.
MSDN Magazine January 2010
This article describes methods for designing screens in a user interface and the technology frameworks that support screen design.
Ambrose Little, Charles B. Kreitzberg
MSDN Magazine September 2009
The end goal of software projects is to deliver value to the customer. Software design is a major factor in how successfully a team can deliver that value. The best designs are a product of continuous design rather than the result of an effort that tries to get the entire design right up front. This approach lets you strive to apply lessons learned from the project to continuously improve the design, instead of becoming locked into an erroneous design developed too early in the project.
MSDN Magazine August 2009
Use Test-Driven Development with mock objects to design object oriented code in terms of roles and responsibilities, not categorization of objects into class hierarchies.
MSDN Magazine June 2009
Designing testability into your app means smaller tests that are cheaper to create, easier to understand, faster to run, and much simpler to debug.
MSDN Magazine December 2008
Test-driven development (TDD) should be on every developer's radar screen because a comprehensive set of tests makes for maintainable code and frees you from having to create a perfect design up-front. This article explains how to perform TDD and takes you step-by-step through a number examples to get you started.
Will Stott and James Newkirk
MSDN Magazine April 2004
I'm looking more for SSAS 2008 best practice design advice, rather than for an answer to a specific question (although I have a specifc set of examples).
First issue: Creating a non-additive measure group and an additive measure group. We have some fact data in our current cube that is additive, and some fact data that is non-additive; all stored in the same fact table. We do not currently
have measures implemented that reflect this aggregation distinction. Question: Is it considered good practice to segregate additive and non-additive fact data into a) different fact tables and/or b) different measure groups? My thought is
that it would be an acceptable design approach, but am looking for feedback.
Second issue: Non-additive fact data is only available at a non-leaf grain. The example here is that we have non-additive fact data which is only available for the 4th or 5th levels of our 6-level geography dimension. Our solution has been
to create a custom geography branch, which now essentially serves as our 'aggregation treatment' for non-additive fact data. I don't believe it's a good practice to have the geography dimension serve this function because we end up having to create a
custom geo member for each non-additive fact data element. Question: What is considered best practice