In his current project at a big Dutch bank Yatish works with the domain driven design (DDD) approach, which is in fact an architectural design pattern, and it helps to keep bad data away. Yatish: ‘As an example I like you to think of a bank where there are individuals and organizations as entities and there is always a relationship between them. So in creating features in your domain you always have to consider what happens to the relationship between the entities. A customer of the bank is deceased and before you start deleting  this person in the database you have to think whether there are other entities related to that person or not. You can’t close something without considering all the implications of it.’

According to Yatish you always have to keep the whole picture in mind. ‘If you only focus on what is necessary to close that particular feature, the result can be that the domain data becomes inconsistent. In ING we had a lot of this bad data in our system which gave our customers unexpected errors. Because of that we had to do a lot of defending programming and to develop software to take care of that problem. That is why we chose the domain first development approach where you cannot create an invalid object. Ofcourse you start to define your domain first, even before you write any exposing service for your customer. This domain is a good piece of architecture pattern with multiple layers. It does not start on the outside, like when you peel an onion but you have a small piece first and then put layers on it. The first focus will be that data which comes in should fit in my domain and must be tested as well because the domain should be solid as a rock.’

To start a domain first approach you have to build blocks for valid objects. Yatish: ‘To stay with the example of the bank. In the domain it should be clear that the person comes from a valid country and has a valid name before you create any other feature. It is always a challenge to keep bad data away. This kind of architecture is useful everywhere. And if a company grows bigger it is always a struggle to keep good track of the functioning and the domain first approach is a big help then. It does not require a special technology or language, it is language agnostic. Think of it as just an architectural design pattern. Another example: If we think of a tree, you are not concerned with the leaves but start with the whole of the tree first, your domain. Otherwise said: It comes from the inside and goes to the outside. It is a sort of paradigm shift, a conceptual thing and some developers need time to get used to it because they are always busy on the consumer side or want to test things. In the new approach they have to define their domain first and every object should be validated.’