SitePoint Sponsor

User Tag List

Results 1 to 16 of 16
  1. #1
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,777
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)

    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...



    Any expert thoughts on this??

    Sincerely,


    Debbie

  2. #2
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,151
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    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.
    The only code I hate more than my own is everyone else's.

  3. #3
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,777
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oddz View Post
    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...

    Code:
    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"...

  4. #4
    SitePoint Evangelist
    Join Date
    Oct 2005
    Location
    Michigan, USA
    Posts
    434
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    #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.
    - Robert

  5. #5
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,151
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by QMonkey View Post
    #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

    Quote Originally Posted by DoubleDee
    P.S. Maybe you could explain more what you mean by "standard registration pattern"
    Single user per screen name.

    Quote Originally Posted by DoubleDee
    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?"
    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.
    The only code I hate more than my own is everyone else's.

  6. #6
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,777
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by QMonkey View Post
    #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).
    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.


    Quote Originally Posted by QMonkey View Post
    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.
    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

  7. #7
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,777
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oddz View Post
    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.
    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?!

    Sincerely,


    Debbie

  8. #8
    SitePoint Evangelist
    Join Date
    Oct 2005
    Location
    Michigan, USA
    Posts
    434
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    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.
    - Robert

  9. #9
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,777
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by QMonkey View Post
    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!

    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"...

  10. #10
    Community Advisor bronze trophy
    fretburner's Avatar
    Join Date
    Apr 2013
    Location
    Brazil
    Posts
    1,405
    Mentioned
    45 Post(s)
    Tagged
    12 Thread(s)
    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.

  11. #11
    SitePoint Evangelist
    Join Date
    Oct 2005
    Location
    Michigan, USA
    Posts
    434
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    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. It could work but is probably limiting.
    - Robert

  12. #12
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,272
    Mentioned
    18 Post(s)
    Tagged
    0 Thread(s)
    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.

    PHP Code:
    $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);
        */

    "First make it work. Then make it better."

  13. #13
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,777
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by QMonkey View Post
    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.
    All valid questions!


    Quote Originally Posted by QMonkey View Post
    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. It could work but is probably limiting.
    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...

    Code:
    Actor		Use-Case		Objects
    ------		---------		--------
    Applicant	Apply for Benefits	Person
    					Application
    					Benefits
    
    Recipient	Use Benefits		Person
    					Application
    					Benefits
    					Account*

    Code:
    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

  14. #14
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,272
    Mentioned
    18 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DoubleDee View Post
    I agree with Jeff in that "Person", "Benefit" and "Application" would be Entities/Classes as far as the *implementation* goes.
    The schema could be modeled in exactly the same way.

    person
    -------------------
    | id | name | etc |
    -------------------

    benefit
    ------------------------------
    | id | cost | coverage | etc |
    ------------------------------

    application
    ----------------------------------------
    | id | applicant_id | benefit_id | etc |
    ----------------------------------------


    A person's role as applicant can be inferred by whether they have a related application record.
    "First make it work. Then make it better."

  15. #15
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,151
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    The schema could be modeled in exactly the same way.

    person
    -------------------
    | id | name | etc |
    -------------------

    benefit
    ------------------------------
    | id | cost | coverage | etc |
    ------------------------------

    application
    ----------------------------------------
    | id | applicant_id | benefit_id | etc |
    ----------------------------------------


    A person's role as applicant can be inferred by whether they have a related application record.
    ditto
    The only code I hate more than my own is everyone else's.

  16. #16
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,777
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oddz View Post
    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


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •