Monday, 13 December 2010

Software Design Patterns and Processes

It is strange how much an architect can understand going through the design process of a system. I have tried a few approaches and I have studied a few more, all in all I am inclined to believe that DDD gets the best out of a software developer.


I won't get into the details of DDD as the reader can get enough info around the web. It hard to get a grip of it though and I would recommend even the average developer to get some books. Thus, I strongly believe that whoever is serious about DDD should get the following:
Truth is there are quite a few, brand new design processes. They are not widespread yet but they are gaining a lot of ground and anyone serious about designing large enterprise systems should have a serious look at them. I am going to give a bunch of links here and I will discuss each of them as we go, in new posts.

First we go with BDD or Behaviour Driven Design, an agile approach base on users and clients behaviours, trying to figure out what they want from the system. Then we have STDD (Story-Test Driven Design, which is quite interesting as we try to involve the customer to the whole process. Finally an approach not so high level is CQRS, meaning "Command and Query Responsibility Segregation". I am a bit sceptical about it yet as i think it tries to say the obvious but I won't try to present any conclusions here yet.

It is important for a developer to know why and how it chooses the design process for each project. The ability to learn a domain and quickly design a solution that fits into it separates great developers from great architects. I have met a few people with extraordinary programming skills (seriously!) who when confronted with a complex domain were intimidated. It takes time and a great amount of experience to get a grip on a domain. It is a continuous effort which, unfortunately, not many people are determined to give (especially where I live...).

No comments:

Post a Comment