Domain Class and responsibilities

[Ingudam Manoranjan]

What are the expected responsibilities of a Domain class?

For example, let's have a Customer as a Domain.

Customer{
String Name;
String Id;
String Address;
...
...
 
}

1) Is persisting in Database part of it? If not, how will it be done.
e.g: something like Customer Creation Usecase. Should it be the responsibility of the Service, say we have a Customer Service. Service Creates Customer in memory, and calls repository and persist the Customer.

2) If above is the case, Transaction boundary will be the responsibility of the Service not the Domain.

[Stan James]

I like to see a persistence layer separate from the domain, so you can pass a domain object in and say "persist this" somewhere. You might have to hand write a data access object for each domain object, or you might use a generic tool that maps objects to database tables or whatever. Does that sound good?

[Ilja Preuss]

Putting persistence logic into a domain object would violate the Single Responsibility Principle: domain logic and persistence logic change for very different reasons and at different rates, so they should be decoupled from each other.

[Ingudam Manoranjan]

Thanks Stan , Ilja for the valuable inputs. I understand the need to have different classes handling the persistence responsibility while the domain class does have the domain attributes and responsibility.