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.

Possible duplicate of [Understanding domain objects/services](http://stackoverflow.com/questions/5589141/understanding-domain-objects-services) — Reloecc, Jan 05 '16 at 20:31
okay, it says: "Domain objects are the data and domain services are the do-stuff-with-the-data part.". So I have to do all the if's in the service section, while have the $member stored in DO? — Mikołaj Marciniak, Jan 05 '16 at 20:34
also, according to this answer here: http://stackoverflow.com/questions/5863870/how-should-a-model-be-structured-in-mvc?lq=1 , "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." — Mikołaj Marciniak, Jan 05 '16 at 20:35

score 0 · Answer 1 · answered Jan 05 '16 at 21:07

0

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()

answered Jan 05 '16 at 21:07

Reloecc

256
2
13

i cant figure namespaces out. also, you are right about what you wrote, but it doesnt answer my question. My question was - why do I need domain objects? If you look at this line: $authenticationResult = $domainObject->checkPassword( $member['password'], $_temp_sess_password ); This can be substitutded with a simple IF statement that will eliminate the need for using RAM resources for creating a new object. – Mikołaj Marciniak Jan 05 '16 at 21:17
then alter your question to something like "why to keep model logic in the model and not in the controller" if you are insterested in.. – Reloecc Jan 05 '16 at 21:21
the way i asked is perfectly valid mate. – Mikołaj Marciniak Jan 05 '16 at 21:22
Then my answer is valid as well, glad to help :) – Reloecc Jan 05 '16 at 21:23
no, you answer doesnt answer my question at all. you just tell me to use namespaces, and rewriting the creation/fetching of the domain object that in the end gives the same result. my question was regarding the checkPassword method. why its even necessary to create a seperate object just for that action. – Mikołaj Marciniak Jan 05 '16 at 21:25
I am sorry, I really want to help you. But I want to leave the answer that correspond with the question. You mentioned "why using checkPassword" in comments only. The term "domain object" stands for "model objects used in particular domain". You use them to keep logic of domains separated from each other. And btw I did not suggest you to use namespace, but the classnames (with or w/o namespace, not relevant). – Reloecc Jan 05 '16 at 21:33
Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/99860/discussion-between-reloecc-and-mikolaj-marciniak). – Reloecc Jan 05 '16 at 21:34
I see that, but can you then elaborate on why I cant substitute the checkPassword method with a "if ($_temp_sess_password != $member['password']) { //do stuff here } ? – Mikołaj Marciniak Jan 05 '16 at 21:36

Am I using Domain Object correctly?

1 Answers1