1-15 start/2007-02-28/1

And if a tell you that we keep an hashtable/structure with the mapping state->{elements in that state}. And that we identify that structure as and important concept in our domain. And for efficiency reasons that structure is mapped into a view like the examples above. In many cases we can transform a problem to match a pattern more familiar to DDD.

But this a different approach to my stance in DDD. I believe that in terms of the Domain of the application, this concept is not relevant at all.. It stands as a solution to a problem that arises from our choices of the programming architecture/methodologies. This part should be of no concern to the domain logic, and I currently think that it should be presented as an infrastructural service to the application.

Edit: I think it stands more clearly if I'd ask you to explain to a client the need of a business representation of a search concept. In terms of his business, it is meaningless, therefor it does not belong to the domain.