The Problem with Extensibility :
                        Consider a scenario where we have to architect a large application, which has a lot of smaller components , and responsible for creating and running them. The simplest solution is to have a hard dependency and call them from the code. But the major drawback in this approach is that you cannot add components without modifying source code, not a ideal approach in a client application scenario.

A slightly different approach in this is to provide extension points through interface, thereby achieving a decoupling between the application and its components. But the problem in this approach is that the application lacks any capacity to discover the components it should load and this is often accomplished by explicitly specifying in the configuration file. And this is not that helpful in client application scenario, where we expect the end user perform the configuration when new components are getting added.

Instead of this explicit registration, MEF offers a way to discover them implicitly, via Composition. A MEF component is called ‘Part’ which often specifies the ‘Imports’(dependencies)  and ‘Exports’(Capabilities).

When a part is created, the composition engine satisfies its ‘Imports’ with what is available from other part (which is understood through their ‘Exports’).

MEF allows applications to discover and examine parts by their metadata, without instantiating them or even loading their assemblies. As a result, there is no need to carefully specify when and how extensions should be loaded. In addition to its provided exports, a part can specify its imports, which will be filled by other parts. This makes communication among parts not only possible, but easy, and allows for good factoring of code.

Composition Container and Catalogs:
The core of the MEF composition model is the composition container, which contains all the parts available and performs composition. (That is, the matching up of imports to exports.)

 A catalog is an object that makes available parts discovered from some source. MEF provides catalogs to discover parts from a provided type, an assembly, or a directory. Application developers can easily create new catalogs to discover parts from other sources, such as a Web service.

MEF site has lot of articles/tutorials/samples on this. http://mef.codeplex.com/

Check it out !!

dynamic :
This is one of the new types included in .NET 4.0. This is a static type but an object of type dynamic bypasses static type checking. We don’t have to be concerned about whether the object gets its value from a COM API,from dynamic languages, from reflection or from HTML DOM. If the code is invalid, the errors are caught at runtime.

The Dynamic Language Runtime (DLR) , in .NET 4.0, provides the infrastructure that supports the dynamic type in C#. The purpose of the DLR is to enable a system of dynamic languages to run on the .NET Framework and give them .NET interoperability.

Covariance and Contra variance :
Covariance enables you to use a more derived type than that specified by the generic parameter, whereas contra variance enables you to use a less derived type. This allows for implicit conversion of classes that implement variant interfaces and provides more flexibility for matching method signatures with variant delegate types. Variant interfaces and delegates can be created by using the new in and out language keywords. The major advantage is hidden in this simple line, which didn’t compile until C# 4.0:

 IEnumerable<Object> objects = new List<String>();

Optional Parameters :
Support for optional parameters allows you to give a method parameter a default value so that you do not have to specify it every time you call the method. This allows you to specify a default value for a parameter like this.

public void Process( string data, bool ignore= false, ArrayList moreData = null )
{}

 Named Arguments :
The order of parameters in a method declaration and the order of arguments you pass when calling the method don’t need to match anymore. You can provide arguments in any order you like by specifying parameter names in a method call. This might also improve the readability of your code.

Office Programmability :
 Access to COM interfaces, including the Office Automation APIs, is greatly enhanced by the addition of named and optional arguments, the dynamic type, indexed properties, and optional ref modifiers.

Model driven design enforces the model and code close to each other. Any domain can be expressed in various models and any model can be expressed in various ways through code. But keeping the model and code relevant to each other will help the project in the long run.

Layered Architecture :  Domain Driven design stresses up on the softwares to follow Layered architecture. This will help us to have a separation of concern. The most common layering scheme that people use is UI- Application – Domain - Infrastructure.

Domain layer is a mandatory thing to have  Domain Driven Design in Place.This is the heart of the business software. The state of business objects is held here.

Infrastructure layer are  mainly stateless and they expose services that the layers above it can use.It provides communication between layers,implements persistence for business objects, contains supporting libraries for the user interface layer, etc.

Application Layer is a thin layer which coordinates the application activity. It does not contain business logic. It does not hold the state of the business objects, but it can hold the state of an application task progress.

To Identify the potential entities for an application, OO design stresses upon finding “the  nouns”. In DDD the the found nouns can be one of the Entites or Value Objects. The ones that have a thread of continuity and Identity is an Entity and the rest becomes Value objects.

Services are those part of application that remains stateless and they contain verbs that is not related with any of the entities or Value objects.

What is a model? A model represents some aspect of reality or an Idea of that is of Interest. It is an Interpretation of reality that abstracts the aspects relevant to solving the problem at hand and ignores extraneous detail.

Domain Model: A Domain model is not necessarily a diagram. It is the rigorously organized and selective abstraction of the domain knowledge. In the words of Eric evans ” It is more like movie making loosely representing reality to a particular purpose”. In DDD three basic uses determine the choice of a model.

1. The model and Implementation should have an intimate link between them. This will make the model more relevant. This ensures that all the analysis that is done based on the model is applied on the software. It also helps during maintenance and continuing development.

2. As the model and Implementation has a deep link, the team can use a language (ubiquitous language) that is based on the model for communication. This will help the team to talk to the domain experts without translation.

3. Model becomes the distilled knowledge of the project and  it helps the team and domain experts to collaborate effectively and wrestle information.

There are certain Ingredients to effective modelling.

1. Binding the model and Implementation
2. Cultivating language based on Model
3. Developing a Knowledge rich model
4. Distilling the Model
5. Brainstorming and Experimenting

In old Waterfall method, we have domain experts who talk to analysts and they pass that information to developers who build the software. This approach is a failure because it completely lacks feedback and the knowledge trickles in one direction.

In DDD, the domain modelers plays the role of Knowledge crunching. The entire team communicates to domain experts using ubiquitous language, based on the model and they crunch the knowledge and put that in the model. The models are never perfect and they evolve. All projects leak knowledge. The Information is scattered. People who have learned something move one. In these cases an effective model rescue the team as it contains the knowledge that is needed.

Why Projects Fail : There are various things that can put a project off course , bureaucracy, unclear objectives, lack of resources, to name a few, but it is the approach to design that largely determines how complex software can become.When complexity gets out of hand, the software can no longer be understood well enough to be easily changed or extended. By contrast, a good design can make opportunities out of those complex features.

Most of the design factor are technological, and a great deal of effort has gone into the design of networks, databases, and other technical dimension of software. Books have been written about how to solve these problems and developers have cultivated their skills and followed technical enhacement.

Yet the most significant complexity of many applications is not technical. It is in the domain itself, the activity or business of the user. When this domain complexity is not dealt with in the design, it won’t matter that the infrastructural technology is well-conceived. A successful design must systematically deal with this central aspect of the software.

Eric evans puts forward Domain Driven design,which stresses upon 2 points:

1. For Most software Projects,the primary focus should be on the domain and domain logic

2. Complex domain designs should be based on a model.

Domain Driven Design, stresses that the focus while developing any project should be on the domain it is operating in.The software has to fit harmoniously with the domain it has been created for.The best way to do it is to make the software a reflection of the domain Itself.

 ”It’s amazing to me that thousands upon thousands of people travel by car every day, accomplishing their goals in a framework of simple traffic rules, with no central control or dispatching service. It also amazes me that when I want to ship a package, I can enter a pickup request on the shipper’s Web site and a driver will arrive at my door before the time that I specify. The driver isn’t dispatched to each house; he or she receives a continually updated list of addresses and deadlines. It’s the driver’s job to plot a route to get all the packages picked up on time.”

“The more complex the system, the more likely it is that central control systems will break down. This is the reason companies decentralize and governments deregulate—relinquishing control to independent agents is a time- honored approach to dealing with complexity. Scrum travels this well-trodden path by moving control from a central scheduling and dispatching authority to the individual teams doing the work. The more complex the project, the more necessary it becomes to delegate decision making to independent agents who are close to the work”

“Scrum dramatically shortens the feedback loop between customer and developer, between wish list and implementation, and between investment and return on investment”

“Scrum turns small teams into managers of their own fate. We know that when we are responsible for choosing our own driving route to Boston, we will find a way to get there. We will detour around construction and avoid rush hour traffic jams, making decisions on the fly, adapting to the independent decisions of all of the other drivers out there. Similarly, Scrum Teams accept a challenge and then figure out how to meet that challenge, detouring around roadblocks in creative ways that could not be planned by a central control and dispatching center.”

“Virtually all process-improvement programs use some version of the Deming cycle to study a problem, experiment with a solution, measure the results, and adopt proven improvements. We call this fact-based decision making, and we know that it works a lot better than front-end-loaded predictive approaches”

“Scrum’s philosophical underpinnings focus on empowering the development team and satisfying customers. Its managerial culture is rooted in helping others achieve their goals. Its technical tools are focused on making fact-based decisions through a learning process. When all of these factors are in place, it’s hard for Scrum not to succeed.”

“Complex problems are those that behave unpredictably. Not only are these problems unpredictable, but even the ways in which they will prove unpredictable are impossible to predict”

 “One vision that comes to my mind when people say they are having ‘success’ is a circus performer juggling balls in the air while riding a unicycle.  Sure, that performer is an amazing expert in his field and extremely talented. However, if his task is to deliver the balls to a customer, he’s spending way too much effort when he could just walk them over to their destination.  Are the talented experts on your team juggling on unicycles, or are they taking the easiest, shortest path?  Which delivery method will make the customer more successful?  Juggling my impress them, but it’s not really helping them”