Is this One or Two Entities?

Just started a new project, and I am stuck on how to best model things…

This is for a system that provides benefits to individuals. An individual applies for benefits, and then is hopefully approved and starts receiving them.

I’m torn whether I should create 1 or 2 Entities for this process.

Scenario #1:
Create one Actor/Entity called “Applicant” for the first part of the flow which is applying for benefits.
Then create a second Actor/Entity called “Recipient” for the second part of the flow which handles if they are granted benefits.

Scenario #2:
Just create one Actor/Entity called whatever - maybe “Customer” - and handle where things are in the process by assigning a “state” (e.g. Applied, Under Review, Approved, Declined)

**NOTE: I am really asking this from a Use-Case/Logical Modeling standpoint as opposed to actual “implementation” in PHP code or whatever. But I figured this was the best forum to ask such a question?!

Off Topic:

Would be nice if SitePoint had a “System/Application Design” forum… :wink:

Any expert thoughts on this??

Sincerely,

Debbie

I would use a standard registration pattern and apply the state of the application to the request for the benefit, not the user itself. That way you would not be pigeon holing the system to a single benefit per registered user.

Not sure if this can occur, but I hear you are saying…


PERSON -||-----|<- APPLICATION
APPLICATION -||-----|<- BENEFITS

I don’t disagree with that, but what I was really asking about in my OP was “Should one physical person be treated as two separate roles/entities in the system, first as an ‘Applicant’ and then later as a ‘Recipient’ or should there just always be a single ‘Person’ entity?”

Sincerely,

Debbie

P.S. Maybe you could explain more what you mean by “standard registration pattern”… :-/

#2 makes sense to me. Just think in real life terms. Imagine you apply for benefits, then you get accepted, then later the benefits are discontinued, then maybe you apply again. In each of these stages you are the same person (client/customer/whatever).

Consider the application. Does it become either an AcceptedApplication or DeniedApplication? No, it would still be an application with a state of accepted, denied, pending, etc.

exactly

Single user per screen name.

Well in the real world when a person applies for benefits do they change into something else. The answer is no. So it makes sense to model that same logic from a technical stand point.

Yes, but…

I am working on Use-Cases and Use-Case Actors. And an Actor is a “role”.

If this was for a Bank ATM, I might have a “Customer” actor and an “Administrator” actor, but they could be the same physical person, just two different “roles”. (Suzie might work at the bank by day and be in charge of managing the ATM, but after work, she would need to use it to get cash for the weekend. Each of those different “roles” would entail her having different interactions with the System as realized by different Use-Cases.)

And that may have answer my original question to a larger degree…

What is still somewhat murky is, “Does the role that a person plays with the System change enough between being an Applicant and a Recipient to dictate having two separate roles in my Use-Case Model?”

Since the Use-Case is more of a “logical” design document, there is probably enough latitude to do things the way I am saying here, OR how you are conceptualizing things.

I agree, but an Application and a Person playing the role of an “Applicant” and later the role as a “Recipient” could be rather different. Whereas an “Application” wouldn’t change in the same way, and would indeed just have different states.

Sincerely,

Debbie

Their “role” does change, though.

And from a “technical” standpoint - especially if you are using OOP - it might be quite common to have a base class called “Customer” and then to have role-based classes (e.g. “Applicant”, “Recipient”) that you apply to that base class via interfaces or whatever the properly technical mumbo-jumbo would be?! :slight_smile:

Sincerely,

Debbie

I see your thoughts regarding the bank example, though in that case I would think the two systems are separate (much risk there).

A similar case might be a grocery store worker. An employee of the store may also be a customer (a customer can register via one of those reward programs). That could go either way. The employee and customer systems can be completely separated and there would be two entities for one individual. OR they could be in the same system as one entity and I can see some benefits there (the employee’s reward program has additional perks). But it would be very understandable to everyone if they were two separate entities.

For an applicant of a service, I think that would be very unexpected. Applying, acceptance, rejection, etc. are all part of one process. If I applied for something and got a user id of 214 then later got accepted and was told my user id is now 532, I would think they didn’t know what they were doing. Why would I be a different user at that point? It could be made to work either way but one way doesn’t seem right to me.

I think we agree except for the last part…

A Use-Case and its Use-Case Actors would not be thinking in terms of a “user id”. (I agree you would want a userID which follows the whole application —> recipient lifecycle, but that is a more detailed level that comes after the Use-Cases.)

So short of me knowing more of the intricacies of how the entire process works, I would say either of my options should be acceptable at a “logical” level.

If it turns out that there are real differences between an “Applicant” and a “Recipient” then I would definitely want to break things out. If there isn’t, then maybe it would be easier to have a single role called something like “Customer”.

Although in my mind, I am thinking I like the two separate role-names better at the Use-Case level.

Why?

Because any yahoo can apply to Harvard, but someone who actually attends Harvard or is an alum is a whole other thing!!!

Similarly, someone who wants State Benefits, and someone who is actually approved to get them is quite different.

And logically, an “Applicant” is anyone off the street, whereas a “Recipient” has been approved and set up in the State’s systems to receive communications, benefits, reviews, and so on. (From that standpoint, they might as well be two different people?!)

But in the end, it is all a matter of perspective and it is also a matter of “What format best captures and communicates the essence of the Business Process and the System?”

Interesting discussion! :slight_smile:

Thanks,

Debbie

P.S. If I was an architect, I would create a parent “Customer” entity and then have two sub-types called “Applicant” and “Recipient”…

I’m guessing it’s possible for an individual to receive more than one kind of benefit? In which case, it’s possible to have a Customer who is currently receiving one kind of benefit while at the same time applying for another. In this situation, it doesn’t seem necessary to have an attribute or role for Applicant or Recipient, as these states are dependant upon having current Benefits or Applications related to the Customer entity.

That’s a good point. In the system I work on now we have Clients which can have any number of Services. When a client is first put in the system it is “pending”. When it has a service it is “active”. If it has no services for a certain period of time it is “inactive”. It’s just one client with a number of different possible statuses. This seems similar to your Customer having Benefits.

Assuming we have the two types of customers (applicant & recipient), what happens when the benefits are ceased? Does it become a third type (former_recipient)? And if the applicant is rejected, does it change there too? This could be a valid way to go but it sure feels like it’s going to get messy.

Now here’s a different view. Maybe there is no customer at the start, just an application which holds all the data. Upon accepting the application, a customer is created. I’m not saying this is a good idea, just a different one. :slight_smile: It could work but is probably limiting.

It seems like each of the nouns could, and perhaps should, be an entity: Person, Application, and Benefit. Here’s how I would envision them working together.

$person = new Person();
$person->setName('John Doe');
// etc

$benefits = new Benefits();
$benefits->setCost(123);
$benefits->setCoverage(456);
// etc

$application = new Application();
$application->setApplicant($person);
$application->setBenefits($benefits);

if (/* some logic */) {
    $application->approve();

    /*
    Presumably $application->approve() would do something such as:

    $this->applicant->addBenefits($this->benefits);
    */
}

All valid questions!

Initially, I liked your thinking, but after a quick thought, here is my counter…

Who fills out an application?

The Application? Gremlins? Or a Person/Customer?

This is sort of similar to the debate with an E-commerce site…

What constitutes a “Customer”?

Is it anyone who visits the website?

Or just people who create an Account and buy something?

In the physical world, most Store Owners see everyone as a “Customer” from the person walking by your store, to someone “window shopping”, to someone just browsing in the isles, to someone who bought something.

Of course you have to take a slightly different approach online, but you see what I am saying?


I agree with Jeff in that “Person”, “Benefit” and “Application” would be Entities/Classes as far as the implementation goes.


The following is going way farther than I intended, but since we are getting all technical here, this is how I see the larger Requirements to Design possibly going…


Actor		Use-Case		Objects
------		---------		--------
Applicant	Apply for Benefits	Person
					Application
					Benefits

Recipient	Use Benefits		Person
					Application
					Benefits
					Account*


State		Object
------		-------
Applied		Person
		Application
		Benefits

Denied		Person
		Application
		Benefits

Active		Person
		Application
		Benefits
		Account*

Inactive	Person
		Application
		Benefits
		Account*

I think that is consistent with Jeff’s point about “Person”, “Application” and “Benefits”.

But back to my OP, I think “Customer” vs. “Applicant”/“Recipient” for my Use-Cases is just splitting hairs…

Sincerely,

Debbie

The schema could be modeled in exactly the same way.

[FONT=Courier New]person

| id | name | etc |

benefit

| id | cost | coverage | etc |

application

| id | applicant_id | benefit_id | etc |
----------------------------------------[/FONT]

A person’s role as applicant can be inferred by whether they have a related application record.

ditto

So would you make one actor named “Person” or was my proposition of have an “Applicant” actor for some Use-Cases and then a “Recipient” actor for other Use-Cases also okay?

(Understanding that most of this thread has turned to discussing “design” which is not the purpose of Use-Cases…)

Sincerely,

Debbie