I think the DDD answer is the first one. Put the logic in the domain object. Inject services if required.

I would have another 'hosting layer' to convert the incoming message to the domain object

The application layer would use domain objects to achieve the required effect.

However. I don't think DDD fits the service pattern very well. In my mind the logic often belongs to the service, not the domain object.

Ie. I would have RecordPlayer.PlayRecord(record) rather than Record.Play()

Plus the nature of these services is that they are stateless, I play a record, return the result and throw everything away.

Whereas in a desktop app DDD works better. I might have several records instanciated and perform various functions on them over time. Get from shelf, play, pause etc. DDD style code matches the users actions and thought process. 'I play this record' -> record.Play()

I think the DDD answer is the first one. Put the logic in the domain object. Inject services if required.

I would have another 'hosting layer' to convert the incoming message to the domain object

The application layer would use domain objects to achieve the required effect.

However. I don't think DDD fits the service pattern very well. In my mind the logic often belongs to the service, not the domain object.

I.e. I would have RecordPlayer.PlayRecord(record) rather than Record.Play()

Plus the nature of these services is that they are stateless, I play a record, return the result and throw everything away.

Whereas in a desktop app DDD works better. I might have several records instantiated and perform various functions on them over time. Get from shelf, play, pause etc. DDD style code matches the users actions and thought process. 'I play this record' -> record.Play()

I think the DDD answer is the first one. Put the logic in the domain object. Inject services if required.

I would have another 'hosting layer' to convert the incomming message to the domain object

The application layer would use domain objects to achieve the required effect.

However. I don't think DDD fits the servive pattern very well. In my mind the logic often belongs to the service, not the domain object.

Ie. I would have RecordPlayer.PlayRecord(record) rather than Record.Play()

I think the DDD answer is the first one. Put the logic in the domain object. Inject services if required.

I would have another 'hosting layer' to convert the incoming message to the domain object

The application layer would use domain objects to achieve the required effect.

However. I don't think DDD fits the service pattern very well. In my mind the logic often belongs to the service, not the domain object.

Ie. I would have RecordPlayer.PlayRecord(record) rather than Record.Play()

Plus the nature of these services is that they are stateless, I play a record, return the result and throw everything away.

Whereas in a desktop app DDD works better. I might have several records instanciated and perform various functions on them over time. Get from shelf, play, pause etc. DDD style code matches the users actions and thought process. 'I play this record' -> record.Play()