Non-Data Classes Part of Model?

Question

Are non-data classes (that are not representing anything in the database) still considered a part of an application's domain model or not? Would you put them together with your Linq2Sql domain model or somewhere else??

Edit: Info about classes: For example, I have a "StatusMessage" class which is instantiated under certain circumstances, and may be discarded, or displayed to the user. It has nothing to do with data from the database (neither retrieval nor storage). Another example is an "Invitation" class. Users on my site can 'invite' each other, and if they do, an Invitation class is created which will encrypt some information and then output a link that the user can give to someone else. I have >25 of those classes. They are not for data transfer, they do real work, but they are not related to the database, and I wouldn't say they are all 'helpers'?! ....

Answer 1

It depends.

If these classes represent a combination of data coming from different tables, process data, take decisions and orchestrate operations, I would consider them business level entities and keep them in the business layer.

If these are some kind of helpers, then it will depend.

ADDED: After having read you extra info on those classes, I think many of them would deserve a rightful place in your business logic. You may wish to draw a line between a domain model and business logic. I suppose you consider you domain model to only contain database mapping classes and that's fine. But then there are also business rules, worker classes that accept user input, process it, take decisions and invoke necessary operations to enact them. These could include CRUDing something to the database, sending email notifications, initiating scheduler tasks, notifying other services etc. For many actions their result will only be distantly reflected in the database, some values may be changed, but not like a complete business object state goes directly to the database. Therefore, it would make sense to keep them together in a dedicated layer.

Another option would be to put the logic of those classes into stored procedures thus persisting it in the database. What doesn't fit there may be grouped together as helpers.

With "StatusMessage", it may not be necessary to have a separate class for that. Messages belong to the view level. A class could just decide on which message to show but then the real display work will take place closer to the UI.

Answer 2

Domain model is data pertinent to the domain. It can come from any source, could be one way (e.g. calculated and persisted only, and never read back). The database is just one domain data persistence strategy.

So yes the data from different places could be part of the domain model.

Personally I would consider a message to be more of a view model entity, whereas the state indicating the requirement for particular messages could be in the domain model. In the case of the invite I would have said that the message flows through to a service and thus becomes domain data - that is ultimately passed to and I suppose becomes domain data pertinent to the other user (and say displayed using some other view model).