DOMAIN DRIVEN DESIGN - Clear Your Concepts Before You Start!

Start Developing a New Application

What we traditionally do when we start a business application? We read the spec and find the functionalities. We break down tasks. In most of the cases the goal of the breakdown is to come up with an estimation and plan of works. We do the estimation. We distribute the works among team members. We design the database schema - sometimes by the team leader or sometimes by the respective developer. We start coding.

So?  What’s wrong with this approach? We have been doing good! Don’t we?
The answer is YES and NO! Yes we are doing good in delivering our projects. But NO! We are not doing good in maintaining and extending our projects!

Think about all of the projects you have worked last few years in the traditional approach. Did you ever face any of the issues below?

1. Your project has the same functionality implemented in the same way or different in different places.
2. You have more than one object for the same item.
3. You have objects that have properties that are not actually attributes of that object.
4. You have no or very poor relationship among related items.
5. Looking at your objects it is not possible to understand what actually the whole application is all  about.

I am sure you have been facing these issues regularly. But do you know why?  The reason is, traditional approach do not guide us designing the system in Up to Bottom fashion. Rather it tempted us to design the system in Bottom-Up fashion. See, when you design a system you need to know what as a whole the application will do? What is the goal the client is trying to achieve? Then, from the top level goal you come up with different smaller functionalities that will eventually allow the users to achieve the top level goal.

But when you design in bottom-up approach, you first design for the granular functionalities, and you have little or no knowledge how this functionality will be used from the Top level and how the Top level functionalities will actually look like.

Have you ever heard that a developer of your team is talking like he does not have the domain knowledge of the whole application? Perhaps yes! I think you can understand the reason. Cause, the design of the application does not represent the domain of the system. And so, developers know only the portions they worked. This is Sad! Isn’t it?

So, is traditional approach – “Designing the application starting from database” a throw away concept?  Not really! But if you have a complex application to develop, this bottom-up design approach does not dictate you to come up with a proper object oriented design.

What is the solution then?

The solution is DDD (DOMAIN DRIVEN DESIGN).

What is DDD?

Domain-driven design is not a technology or a methodology. DDD provides a structure of practices and terminology for making design decisions that focus and accelerate software projects dealing with complicated domains.

- Wikipedia

Concepts to cover in this article:

1. Understanding the Domain.
2. Ubiquitous Language.
3. Contexts and Bounded Contexts.
4. Entities and Value Objects.
5. Aggregates and Aggregate Roots.
6. Persistence Ignorance. 
7. Repository. 
8. Domain Service. 

In this article I will try to avoid becoming too technical, rather I will try to go through different concepts of DDD being close to the real world.  I will try not to show any code here. Because I believe if you understand the concept and starts thinking in DDD way, implementation is easy. The toughest part is to tune your thinking process!

Understanding the Domain

A sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software.

- Wikipedia

Do you get a feeling what is domain from this definition?  Can you tell what is the domain of the project you are working on at this moment? Can you tell what is the domain of the famous website YouTube?

In this article I would like to go through a real world example to give you the feeling how to start analyzing your project driven by your domain. This example may not be related with application development but as the goal is to tune our thinking top to bottom manner, it will be useful. But again, we will go through the technical terms of DDD too!

Let’s say you are engaged to design a building. The requirement is:

• You have a defined amount of land
• Your building will have 6 floors.
• Each floor will have 4 apartments.

What is your domain here?

The domain is Building(?). It could be. But note that, if you consider Building as your domain you may miss few granular details for your requirement. The building you are going to design must have design for apartments where people will live. So, a general term “Building” can make us miss few details. So, we may narrow down our domain to “Residential Building”.

Now, when you talk about your work with engineers and also with the people who engaged you to design the building, the term “Residential Building” is more meaningful for everybody concerned. Did you mark very small change in language here? The contractor is telling you to design a building where there will be 4 apartments in each of the 6 floors. Now, if you send an engineer to the site telling him we will need to construct a building there, they might not consider many attributes that a residential building must have. On the other hand if you use the term “Residential Building”, most likely he will come with a valid analysis.
This is how we come to an “Ubiquitous Language”.

Ubiquitous Language

The concept is simple, that developers and the business should share a common language that both understand to mean the same things, and more importantly, that is set in business terminology, not technical terminology.

More Example of Ubiquitous Language:

Example 1:

Wrong Language:

The length and width ratio of the smaller bed rooms would be 4:3.

Correct Language:

The children's bed room’s length will be 20 ft and width will be 15 ft.
Note that, to the owner of the building “smaller room”, “ratio” - all these things could be very technical terms. Rather it is easier for him to understand children's room, guest room, living room etc. And explicit measurement is more meaningful to him.

Example 2:

Let us see an example from software perspective.

Wrong language:

In search functionality we will consider inflectional and thesaurus feature of sql server to make the search more relevant. Additionally we will also exclude the stop words from the search to make it more accurate.
Note that, your domain expert may not be a technical person and thus he may not understand what you meant by the words “Inflectional”, “Thesaurus”, “Stop word” etc.

Correct language:

In the search functionality we will consider all the synonyms of the search phrase so that it does not exclude relevant results. Moreover we will not differentiate any search word by its number (singular or plural), tense, participle etc so that the result becomes more accurate. Additionally as expected in any search, we will ignore all the noise words that do not have any value in the search. Such noise words could be “am”, “but”, “where”, “about” etc.

Do you see the difference in language here? Really a correct language can make all the involved parties think and understand in the same way.

Let’s come back to our “Residential Building” domain. Look, you can proceed with the residential building design as a single task and address the whole thing together. But will it really be very wise way to do? Note that, if you just consider this a single unit of work you may miss many things. Designing a building is related to so many things. For example: you need to consider ventilation, utility, parking space, community space etc.

Now you see, different other contexts are coming up. This is how the concept “Context” and “Bounded Context” comes up in Domain Driven Design.

Contexts and Bounded Contexts

A Bounded Context can be considered as a miniature application, containing itss own Domain, own code and persistence mechanisms. Within a Bounded Context, there should be logical consistency; each Bounded Context should be independent of any other Bounded Context.
More Example of Bounded Context:

Think of an e-Commerce system. Initially you can tell it is an application of shopping context. But if you look more closely, you will see there are other contexts too. Like: Inventory, Delivery, Accounts etc.

Dividing a large application among different bounded contexts properly will allow you to make your application more modular, will help you to separate different concerns and will make the application easy to manage and enhance. Each of these Bounded Contexts has a specific responsibility, and can operate in a semiautonomous fashion. By splitting these apart it becomes more obvious to find where logic should sit, and you can avoid that BBOM (Big ball of mud) J

What is BBOM?

A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined.

- Brian Foote and Joseph Yoder, Big Ball of Mud. Fourth Conference on Patterns Languages of Programs (PLoP '97/EuroPLoP '97) Monticello, Illinois, September 1997

Our all time objective should be to avoid BBOM

Again with the “Residential Building Domain”. So, we could have several bounded contexts:

• Electricity supply
• Car parking
• Apartment 
• Etc.

Let’s talk about the apartment. The apartment is basically a combination of different rooms. The rooms have different elements inside like windows, doors etc. Now I have 2 questions to you about the windows of the room.

    Question1: Can you imagine a window without a room?
    Question2: Does a window have any identity without the room it is residing in?

Answering these questions will expose the following concepts of DDD.

•     Entity.
•     Value Object.
•     Aggregates & Aggregate root.

Entity

“This is my Entity, there are many like it, but this one is mine.”

The key defining characteristic of an Entity is that it has an Identity – it is unique within the system, and no other Entity, no matter how similar is, the same Entity unless it has the same Identity.

Examples: 

1.     Your bed room in the apartment.
2.     Contract in Facebook.
3.     Article in CodeProject.

Value Object 

The key defining characteristic of a Value Object is it has no Identity. Ok, perhaps a little simplistic, but the intention of a Value Object is to represent something by its attributes only. Two value objects may have identical attributes, in which case they are identical. They don’t however have any value other than by virtue of their attributes. Another aspect common to value objects is that they should probably be immutable, once created they cannot be changed or altered. You can create a new one, and as they have no identity, that is just the same as changing another one.

Example:

1.     Windows in the rooms
2.     Address of any person in your website.
3.     SearchCriteria of your search.

Note:  A value object can become an entity depending on the situation. Can you find a scenario like that? If the requirement of the search functionality of your application says that, the search criteria should be saved in the database and the user can do the same search from the list of saved search criteria’s. In this scenario SearchCriteria has its own identity and thus it is an entity instead of being a value object.

Now you know what entity is and what value object in DDD is. In domain driven design entities and value objects can exist independently. But in some cases the relation can be such that, an entity or VO has no value without its context.

Example:

1.     A window can only be defined if there is a room. 
2.     An order note can only exist if an order is placed.
3.     A question detail can only be there if a question is asked.

Very simple is not it? Believe me, now you know what Aggregate and Aggregate root is in DDD.

Aggregate and Aggregate Root

In the examples given above –

    Room, Order and Question are our aggregate roots.
    On the other hand window, order note and question detail are our aggregates.

“A cluster of associated objects that are treated as a unit with regard to data changes.”

All objects of the clusters should be treated as aggregate.

All external access to the cluster is through a single root Entity. This root entity is defined as aggregate root.

Example:

    A question detail should no way be saved unless the corresponding question is saved.
    A question detail should no way be retrieved unless the  corosponding question is retrieved.

Here Question is the Aggregate root and Question Detail is the aggregate. Aggregates and Aggregates Root are very important concepts of DDD.

So far we have talked about domain, objects/entities, contexts, aggregates etc. What about the Database? Is that something we have missed? Isn’t it something should come in the design?

The answer is NO!  DDD is a persistence ignorant approach.

Persistence Ignorance

In domain driven design your objective is to create a model of the domain. You need to identify what are the items (objects) you need to accomplish the desired functionalities of your application. You need to identify the relationships among different objects and how they interact among themselves. You need to find if the business goal of your client is achievable using your domain model. Where is the existence of database here?  You do not need to know how and where the data of your domain will persist or even if the data do need to persist while you do the model of the domain.

This ignorance about your persistence medium will make your domain model free from any coupling with the persistence layer of the application. This will eventually separate the concerns of the persistence and its communication mechanism from your domain model. In result your application will be free from coupling with any data store and will be very easily unit testable.
But Yes! In a real application you do need to have a database. But your domain model will have no knowledge about that. All it will know is the “Repository” which will eventually manage your application’s persistence concern.

Repository

Can you tell me what the meaning of the English word “Repository” is?

Repository commonly refers to a location for storage, often for safety or preservation.

- Wikipedia

As I have already said your domain model will not know any database. What it will know is, there is a repository in the system and that repository will be responsible to store your data and to retrieve your data. It is no way a concern of your domain model how and where data will persist. So, it can be Sql server, oracle, xml, text file or anything else. I hope now you got a sense what a repository means in DDD.

Let’s become little more technical.

Repository Mediates between the domain and data mapping using a collection-like interface for accessing domain objects. It is more like a facade to your data store that pretend like a collection of your domain.

Repository Is Not A Data Access Layer. 

Note that repository doesn’t talk in terms of “data”, it talks in terms of Aggregate Roots. You can tell your repository to add an Aggregate Root into its collection, or you can ask it for a particular Aggregate Root. When you remember that Aggregate Roots may comprise one or many Entities and Value Objects, this makes it fairly different to a traditional DAL that returns you back a set of rows from your database tables.

Implementation Strategy of Repository:

As I said, Repository is a design pattern that is used in DDD to handle the persistence concern. The detail of this pattern is out of the scope of this article. However, here I am trying tell in minimum how we may achieve a repository implementation.

1. 1st of all you will have an interface - IRepository that should be generic.
2. You will have an abstract implementation of the IRepository interface.
3. You will have interface INhRepository  for your persistence mechanism (i.e. Nhibernate) this will inherit from IReposiroty. 
4. You will have implementation of INhReposiroty in a class like “NhReposirory”.
5. Finally you may have a generic implementation of the repository that will have default implementations of all the common methods of the repository. 
6. Like NHGenericRepository that inherits from NhRepository and implments IGenericNhReposirtory.
7. You will specific repository for you Aggregate Roots, that will be extended from NHGenericRepository.
8. Your application will use service locator to find which repository the application will use. 

Domain Service

Domain service is another important concept of DDD. If Entities and Value Objects are the “things” in your domain, the services are a way of dealing with actions, operations and activities.

Shouldn’t Logic Be on the Entities Directly?

Yes, it really should. We should be modeling our Entities with the logic that relates to them and their children. But, there are occasions when we need to deal with complex operations or external responsibilities or maybe we need to expose the actions of the aggregate roots to the external world. This is why creating a domain service for different aggregate root is a good idea. You can consider the domain services as façade layer of the business logics and operations of your domain.

End Words: 

In this article I have tried to introduce the basic concepts and terminologies of Domain Driven Design with examples of real world. The goal was to make you feel comfortable with DDD world. But really developing applications with DDD is a big challenge. The more you love and practice DDD concepts while you design your object model, the more accuracy you will gain in your design. As I said before the most important thing is, you must think in Domain Driven Way. If you don't you will hugely suffer when your application is a real complex one.

Great DDD Resources 

1. http://www.dddcommunity.org/ 
2. http://thinkddd.com/ 
3. http://www.infoq.com/minibooks/domain-driven-design-quickly 
4. http://thinkddd.com/assets/2/Domain_Driven_Design_-_Step_by_Step.pdf 
5. http://www.dddcommunity.org/library/young_2010 
6. http://www.dddcommunity.org/library/evans_2010 
7. http://blog.fossmo.net/post/Command-and-Query-Responsibility-Segregation-(CQRS).aspx 
8. http://msdn.microsoft.com/en-us/library/ff649690.aspx 

SOLIDify your software design concepts through SOLID

Starting With Real World

If you want to create a dolls house you may easily do that by your own. It does not necessarily need any upfront design. You just gather some materials (say papers) and start building from your imagination.

Give the doll’s house to your daughter. She will play with this and after some time she will not like it anymore. Then you throw it away and build another one.

Now your wife is asking you to build a house on the land you have just purchased. Is it possible for you to build the house by your own? I know this is an invalid question. Well, is it possible for you to start building the house if you are provided 100 people with you? The answer is no. If I ask why? You will instantly give the obvious answer – “Building a house involves lot of concerns and you need experts to handle those concerns before starting the real construction work.”

Some concerns could be

1. Your wife’s dream about the house.

2. The maximum area of land availability.

3. Your budget.

4. Core architectural design.

5. Floor planning.

6. Utility planning.

7. Car parking.

8. And many more.

So, the first point you need to start the work is to talk with your wife generously so that you know what exactly she wants at her house. Then go to the construction company who will work as a contractor to build your house. Tell them your expectation, area and budget. You will then be sent to the civil engineer and the architect. They will know your requirements in detail and will do thorough analysis on that. Later the civil engineer and the architect will come out with a design and plan of construction. They will consider all the concerns and are expected to handle those with maximum efficiency. The best they do it, the best your house will become. On the other hand if the architect and civil engineer do poor work, you house will suffer in the long run.

So, it is not you and the workers who are responsible for a great house to construct but it is the architect and civil engineer who can make it happen of-course backed by skilled workers who are capable of working according to plan. If your design and architecture is great, the hardest part is done.

I am sure as you are reading this article, you are a software engineer. Can you relate this house construction paradigm with the software development world?

Let us construct your house hypothetically as if it is a software and try to relate the design strategies of this house construction with some software design principles so that we can realize the necessity of following standard principles while design our software.

First of all who is the client of this house? It is primarily your wife who provided you the specification of her expectations from the house. Then you are also the client who will be the point of contract from client side. The construction company is the software house who is going to work to build your house. So, an agile environment is setup that can ensure the best production as both parties will be in close touch all the time. Now what?

Now, the architecture and civil engineer will start analyzing your specification to come up with a good design. In reality building a house is a very big task. So, we will not touch too many points to make it simple. The goal will be, the designer should design your building in the best way and we will see it through some example building construction concerns.

Base foundation of the building:

The civil engineer will design the base foundation of the house. He perhaps will consider the following while doing the design:

1. Maximum area of land.

2. Maximum number of floors can be accommodated.

3. How many floors you will want to construct initially.

4. Your plan of extension in future.

Then perhaps,

5. How deep the foundation will be.

6. How many piers will be needed and how they will be distributed.

7. Etc.

During designing the base foundation plan, the civil engineer will need to work closely with the architect so that the distribution of piers does not impact the interior of the building.

Now, once the foundation is done, it is closed. The piers will be extendable and on top of that your house will be extended floor by floor. Let’s say you will construct your house initially with 2 floors. After some years the world under go in recession and you lost your job. So, you want to construct 2 more floors on top of your house using your saved money so that you can give that in rent and earn some continuous money. Let’s say, the engineer had not considered that you may want to construct more floors on your house. So, he designed the foundation just for 2 floors and at the top the piers are sealed. So what will you do now? Unfortunately you have no option but demolishing your house, re-do the foundation and construct it again. So, the engineer could have killed you. Is not it?

On the other hand, if the engineer is good, he will do the foundation so that you can build more floors on top of it and the piers on the top floors are extendable. So, your base foundation is closed for any modification but still open for extension. Here we have learned a very important principle that is also applicable in software paradigm. That is, you must build your base classes of the software with enough knowledge of the module you are developing and then expose the extension points from the base class so that it can be extended by the child classes.

In one sentence we can tell “Your base classes will be closed for any modification and still open for extension.” This principle is formally known as Open-Close Principle in software world.

More example of Open-Close Principle:

See the example codes below. If you understand the Open Close Principle you will easily see how the 1^st example violating the Open Close Principle and how the second example honoring it.

Image – Violation of Open Close Principle

Image – Honoring Open Close Principle

Interior Architecture – Where to fit Air Conditioners:

As I have already said, there are so many concerns we will have to handle to construct a house. Among all those concerns very small concern like where to install your air conditioner in your bed room is no less important. Say, your architect designed the room so that you have a space for fitting air conditioner inside the window. During his design he thought of a window air conditioner and kept a place for that in the window. Now, the time changes, and you may like to install a bigger air conditioner or you may like to install a split ac replacing your old window one. What will you need to do?

One option is you change your window so that it allows you a bigger space for the ac. But you see if you do this, the size of the window may decrease which eventually may not be good for day light transition and air flow of your room.

So, ideal solution could be if the space for the air conditioner were not inside your window, rather into the wall, you could alter the space for your new ac in the wall engaging perhaps with very low skilled labor.

See the benefits here:

1. You do not need to change your window.

2. Your room will not be at risk of low ventilation and lighting.

Do you see the problem in the design where ac is to fit into the window? We all know that purpose of a window is to provide proper light and ventilation to your room. So, window should have been changed only if you need to adjust the lighting and ventilation. It was not good if you had to change your window because you needed to install a new ac.

This flaw in your build design has similarity with a very important software design principle. The principle says your objects should change for one and only one reason. In other words, your objects should always serve one and only one responsibility. Formally this principle is known as Single Responsibility Principle in software world.

More example of Single Responsibility Principle:

See the simple example below. Here 2 task is done by ApplicationSecurityContext class. One is authentication and the other is Login. You know in modern software world there could be many ways of authenticating users and also many ways to make the user logged to your application. Authentication can be done through database, windows authentication, single sign-on etc and login can be done through forms authentication, windows authentication, LDAP based authentication etc. So, it is natural that your application’s login and authentication mechanism can change. But if you implement both in the same class this class gets 2 very big concern of your application to manage. Here authentication is more of central concern of the system and login is closely related to the client interface of the application (Desktop app, Smart client app, Web app etc). In this situation we must not implement this 2 concern in same class and if we do it will clearly violate the single responsibility principle. And if we continue to mix up these type of concerns in a single class, it will become a BBOM gradually.

Image: Violating Single Responsibility Principle

What is the solution then?

Image: Honoring Single Responsibility Principle

We can create a separate class for authentication. The best approach will be to have an interface like IAuthenticationProvider and implement your desired authentication implementing the interface. The FormsAuthenticationProvider class implements the forms authentication for your application. Later you can easily implement other mechanism of authentication if required. So, it is honoring both Single Responsibility Principle and Open Close Principle.

Designing the car parking area:

In Modern buildings car parking is one of the very important areas of concern. Your engineer and architect needs to design the piers of your building so that your basement or ground floor can accommodate as many cars as possible. While doing the design, they should consider the type of cars they should support. Normally in residential houses the zips could be the largest vehicle to support. So, your engineer should design the car parking so that each space supports light weight vehicles. Now, if your architect and engineers are not ver careful they may design the space only for sedan cars. The consequence of this, when you will need to accommodate your new prado in your car parking you cannot do that.

So, the design principle should be, each parking space should support one light weight vehicle. In that way it should also support any type of light weight vehicle whether it is a small car or a big prado jip.

This car parking concern also can describe another very important software design principle. The principle says, in a system of an object X is used and if object Y is subtype of object X then, in that system object X should be replaceable by object Y. More formally this principle is called Liskov's substitution principle in software world.

More Example of Liskov's Substitution Principle:

Liskov substitution principle basically says the inheritances that you create in your application must be correct. Here is the classic example for which the Liskov's Substitution Principle is violated. In the example 2 classes are used: Rectangle and Square. Let's assume that the Rectangle object is used somewhere in the application. We extend the application and add the Square class. The Square class is returned by a factory pattern, based on some conditions and we don't know the exact what type of object will be returned. But we know it's a rectangle. We get the Rectangle object, set the width to 5 and height to 10 and get the area. For a rectangle with width 5 and height 10 the area should be 50. Instead the result will be 100. (This example is taken from http://www.oodesign.com/liskov-s-substitution-principle.html )

Image – Violating Liskov Substitution Principle

Electricity Distribution Lines:

Among many of the utilities that you must have in your building electricity is perhaps one of the most important one. Your engineer and architect will perhaps need to work with an electrical engineer to design the electricity distribution line of your building. One approach for this could be, the whole supply of current in your building will come from a single root. But you see this will make the whole supply chain too complicated. It will make it very difficult to manage, extend and trouble shoot. So, what should be the solution?

In fact the electricity line should be interfaced in multiple segments. First of all each floor may have a separate root and then perhaps the best way would be to have each room having separate root. If you follow this design principle, it will be very easy for you to manage and trouble shoot your electric supply lines.

Again, this has similarity with yet another important software design principle. This principle says once an interface has become too 'fat' it needs to be split into smaller and more specific interfaces so that any clients of the interface will only know about the methods that pertain to them. This principle is known as Interface Segregation Principle in software world.

More example of Interface Segregation Principle:

Interface segregation principle is closely related with single responsibility principle I explained earlier in this write-up. Here creating a different interface for IAuthenticationProvider segregating the authentication concern from the login mechanism. In the same way whenever we see a single interface is becoming too heavy and entertaining more than one concern we should segregate the interface and create interfaces for each individual task to perform. Please see the Single Responsibility Principle code block for this example.

Overall building development process:

So far, we have talked about few of the concerns of your building construction. Now let us talk about the process of the building construct. You have engaged the civil engineer and the architect and they have completed the design. Now, the actual construction will start. How will the massive construction work will go through? Definitely there be a team leader. The team leader will eventually have different teams. For example construction workers, electricians, purchase team and so on. Now, to each team the responsibility will be distributed and each team will have a team leader itself. So, the team leader of the whole construction work will just know the individual team leaders of each team. He does not need to know who the team members are working in each team. In this way, the dependencies among different teams are abstracted to individual team leaders. So, any change in the requirement and design will not need to be transmitted to all of the workers working in the project. The job of the works is just to implement what their team leaders ask to do.

So, the principle team leader does not depend on different teams through the team members rather he depends on different teams through the individual team leaders. And individual workers depend on their team leader to know what they need to implement.

This process of building construction can demonstrate another greatly important software design principle. The principle says:

1. High-level modules should not depend on low-level modules. Both should depend on abstractions.

2. Abstractions should not depend upon details. Details should depend upon abstractions.

--Wikipedia

The principle is known as Dependency Inversion Principle.

More example of Dependency inversion principle:

We actually already have seen code example of Dependency Inversion Principle. Again you if look at the code block for single responsibility principle you will see a parameter of type IAutheticationProvider is passed to the method LogIn. Here the client of this LogIn method does not need to know the actual implementation of IAutheticationProvider directly rather it gets the authentication through the abstract layer of IAutheticationProvider interface.

Image - Dependency Inversion Principle
In modern software world there are quite a few dependency injection container that facilitates us to program honoring dependency inversion principle. Some of those are Unity, NInject, Windsor etc. I have plan to have a separate write up on this later. So, keep following 

So far in this write-up I have tried to explain 5 very important design principles that we should always honor while designing and programming our softwares. Collectively these principles are called SOLID.

Image - SOLID copied from wikipedia

Beside these there are some other principles that we should have knowledge about. But again I have plan to write on those later. So, keep watching J.
Thanks for your patience to read this write-up. I would appreciate your comments and feedbacks. Discussions always can boost our concepts and decision making capability for software design.

Domain Driven Design - Explaining in your own language

Recently I have presented in a session at my office on Domain Driven Design. In the session I tried to explain different concepts of Domain Driven Design in a very simplistic manner.

Here is the link:
http://www.slideshare.net/mahmud05/domain-driven-design-10599355

Software Requirement Analysis and Thinking Process towards a good Architecture

Recently I have presented in a session in my office on thinking process towards a good architecture through proper analysis of the requirement. Here is the link of the slides:

http://www.slideshare.net/mahmud05/software-requirement-analysis-and-thinking-process-towards-a-good-architecture