First domain-driven User entity class

I'm still learning about domain driven design, and I have created my first entity class User.

Is this fully compliant with the DDD principles? Particularly my setters because I have business rules in them. Any other suggestions would be highly appreciated as well.

```
namespace Models\Entities;

class User
{
private $id;
private $firstName;
private $lastName;
private $email;
private $password;
private $registerDate;

public function setId($id)
{
if (!$this->id) {
if (is_int($id) && $id >= 1) {
$this->id = $id;

return $this;
}

throw new \InvalidArgumentException('ID must be a positive integer.');
}

throw new \InvalidArgumentException('ID has already been set.');
}

public function getId()
{
return $this->id;
}

public function setFirstName($firstName)
{
if (is_string($firstName) && !empty($firstName) && ctype_alpha($firstName)) {
$length = $this->stringLength($firstName);

if ($length >= 1 && $length firstName = $firstName;

return $this;
}
}

throw new \InvalidArgumentException('First name must be an alpha string inclusively between 1 and 35 characters.');
}

public function getFirstName()
{
return $this->firstName;
}

public function setLastName($lastName)
{
if (is_string($lastName) && !empty($lastName) && ctype_alpha($lastName)) {
$length = $this->stringLength($lastName);

if ($length >= 1 && $length lastName = $lastName;

return $this;
}
}

throw new \InvalidArgumentException('Last name must be an alpha string inclusively between 1 and 35 characters.');
}

public function getLastName()
{
return $this->lastName;
}

public function getFullName()
{
return $this->firstName . ' ' . $thi

Your class can absolutely be considered like a DDD domain entity.
However, I would suggest some improvements:

• DDD likes to use an ObjectValue for the unique identifiers, you could use one instead of a simple integer.

• You could separate the validation logic from the entity (not specific to DDD).

• You should not have a getPassword() method but a verifyPassword($password) instead. Don't expose the password in plain text.

• You could also separate the stringLength() into its own string utility class.

• Regarding the use of a Uniw timestamp, keep in mind that DateTime is a better option since it embeds the time zone. Timestamps don't, which is always confusing when handling dates from all over the world...

StackExchange Code Review Q#57669, answer score: 6