Vinay's Blog

This post was supposed to be about the layering in my sample project, but I thought I would talk a bit about TDD as its new to me. This is by no means an exhaustive post on TDD

Test Driven Development

TDD could be told as an approach in development, where we are writing tests to know the area for which we are building the software. Tests written during the development phase helps you in understanding the domain, and, after development tests helps us document that system. Following are a few things about TDD that I have understood

The Steps

1) We write a failing test. We have to identity whether the test is testing what is intended in this step.
2) We make sure the test written in step 1 passes.
3) We refactor the code written in step 2.

This is a continuation post. You can read the first part here.

Aggregates and Aggregate Root

In a software there can invariably be many objects, and some of these objects are bound to be related to each other in some way. These objects that are related to each other are known as aggregates and an aggregate root is the object that holds them together. Aggregate root is always an entity. Say for example in a blog application a comment would be related to a post. So post and comments become an aggregate and post becomes the aggregate root as there cant be any comments without a post.

Aggregates are to be considered as one unit with regard to any data manipulation and these aggregates can be accessed from outside only through their aggregate root. This mechanism of accessing the objects only by the root helps in maintain data integrity as individual objects can not be changed directly.

What is DDD?

DDD could be called as a methodology or a set of patterns which help us in developing a software pertaining to the domain. Here what domain means, is the actual system for which we are building the software. DDD is not breaking away from the core Object Oriented design principles, but to utilize them in the right way. There are many aspects in DDD which we need to consider when building an application. Following are the aspects and their brief explanations from what I have understood.

The Ubiquitous Language ( UL )

Developers when building a software tend to wholly dwell into the technical aspects of the the application unlike the domain experts who have an extensive knowledge of the problem domain rather than the technical solution for it. When a domain expert is sharing his expertise, he will using a lot of terms that may not be understood by the development team, thus brining in a communication gap between the two. 

If you are closely following the things that are happening around the .NET development arena, there is a lot of interest in DDD ( Domain Driven Design ) along with other TLA’s like TDD ( Test Driven Development), MVC ( Model-View-Controller ) etc. It was hard for me not to notice the buzz around DDD and got me interested in it. As the title says, I would want to see what these things mean and how to develop an application around or rather using these technologies.

Here are the links to all of the 23 GOF design patterns that I have been writing till now. Its in the order that I have been posting.

Structural Patterns

I have been writing about the GOF design patterns for quite some time now, and, this would be the last of the series. I will be writing about the Memento pattern today which is  a behavioral pattern. You can read about the other patterns from the following links.

Following up on the series on design patterns, I will be writing about the Interpreter pattern today. Interpreter is  a behavioral pattern. You can read about the other patterns from the following links.