DDD: Can immutable objects also be entities

Everything that has an identity should be an Entity, and everything that does not have an identity is a simple value, hence a value object.

To quote Martin Fowler (which in turn qoutes Eric Evans)

• Entity: Objects that have a distinct identity that runs through time and different representations. You also hear these called "reference objects".
• Value Object: Objects that matter only has the combination of their attributes.

Reason to make your address a Value Object:

If your address is mutable, you will likely screw up your mailing history in the end. For example, if you're shipping items to an customer, you can't be sure to which address you actually shipped something in the past if the address your MailingHistory table is referring to has been changed.

The MailingHistory entry We shipped A764 to address 657 could mean We shipped article A764 to Boston yesterday and We shipped article A764 to New York tomorrow.

If the mailing address has to been changed, there's no need to delete the old one. Keep it, and mark it as inactive, and the new one as active.

Of course you could treat your address as a Entity, but only when updating it would not change the actual place the address is referring to, hence only allowing the correction of typos.

If you're sure you could ensure that, than using an Entity would be possible.

But the best solution IMHO is to not referrence an address Entity in your mailing history, but rather save the specific address directly in your mailing history table (basically copying the data of the address).

This way, you always know where you shipped your stuff (or whatever you are mailing), and since you would use a mutable Entity, your address table won't be cluttered up.

I've worked with/on several ERP systems, and nearly all of them used this approach.

You will have some redundancy in your database, but it's the most pragmatic way IMHO.

1) The models of books in different stages refer to the same book. I wouldn't say that they refer to the same underlying concept because the concepts are different in the different contexts. They do refer to the same book in that the identity of the book is shared among the BCs.

2a) As with the book, they refer to the same identity but express different aspects of that identity in a specific context. Sort of like a single object implementing multiple interfaces which embody the roles that object plays.

2b) It isn't duplication of concepts because the concepts are different, only the identity is shared. Remember, the goal of DDD and programming in general is to create a model of your domain. All models are incomplete, but good models provide utility.

2c) You can say that a Moderator is a role played by a user in a specific context.

3) Same as above. They refer to the same identity, the same person, but different roles.

UPDATE

Does having two model elements ( both within same BC ) , each representing different aspect of the same underlying concept, result in what Evans calls duplicate concepts?

I don't recall what Evans called duplicate concepts so not sure.

I thought terms "representing different aspects of an identity within particular BC" and "representing different aspects of the same underlying concept within particular BC" are interchangeable ( ie they mean the same thing )? If not, how do they differ?

This may be a linguistic issue. The way I see it, an identity can have different concepts associated with it depending on the context.

I assumed each role represents a particular aspect of the underlying concept, but you're saying it doesn't? What then does role model and how is the thing that role models conceptually different from an aspect of the underlying concept?

Again this seems to be a linguistic issue. You use "underlying concept" to refer to identity which I think isn't clear enough to distinguish from simply "concept" which by itself isn't sufficient.