Am I using Domain Object correctly?

Question

According to this article here

You can think of them [Services] as "higher level Domain Objects", but instead of business logic, Services are responsible for interaction between Domain Objects and Mappers. These structures end up creating a "public" interface for interacting with the domain business logic. You can avoid them, but at the penalty of leaking some domain logic into Controllers.

I have been reading up on MVC, and ive split the M part into Services, Domain Objects and Data Mappers. Services and Data Mappers are easy to figure out, but I dont understand the reason for domain objects, can you please give me some examples? Here is my code:

MemberService

class MemberService extends Service
{
    public function authenticate()
    {
        $domainObject = $this->domainObjectFactory->getDomainObject('Member');
        $dataMapper = $this->databaseFactory->getMapper('Member');  

        $_temp_sess_id = 0;
        $_temp_sess_password = "";

        $member = $dataMapper->fetch( $_temp_sess_id );
        $authenticationResult = $domainObject->checkPassword( $member['password'], $_temp_sess_password );

        if (!$authenticationResult)
        {
            $member = ['user_id' => 0];
        }

        return $member;
    }
}

MemberDomainObject

class MemberDomainObject extends DomainObject
{
    public function checkPassword( $dataMapperPassword, $locallyStoredPassword )
    {
        if ( $dataMapperPassword !== $locallyStoredPassword )
            return false;
        return true;
    }
}     

UPDATE:

This question is regarding the method checkPassword and why its necessary to create a separate object just to use an IF statement that could be used inside the service instead, saving RAM from using additional resources for creating a new object.

Answer 1

You've just created a MemberDomainObject trough some factory in your example. The code you are showing has none to zero informational value for this purpose.

You need to make a real app with few objects, services and two domains at least, so anybody can say "you are using domain objects well".

Aren't you interested just in "model objects"? No need to talk about domain objects if you need to be sure about correct "service > factory > model object > mapper" relation using.

---

Creating objects via factory is good practice as you can alter or add contructor calls during refactor in one place.

one advice is: use class names with namespaces (FQN) in your factories, it helps you with navigating trough code and with refactoring as well

$member = $this->domainObjectFactory->getDomainObject(MemberDomainObject::class); //in php5.5+

you can substitute with

class DomainObject
{

   static function className(){
      return get_called_class();
   }
}

$member = $this->domainObjectFactory->getDomainObject(MemberDomainObject::className());

in php <= 5.4 and replace it on upgrade.

as same as the

$member = $this->domainObjectFactory->getMember();

is not an issue, as you can specify the returning type in ::getMember()