Deciding How To Split Up Architecture Using If Blocks

Question

I'm having trouble deciding the best way to handle splitting up if block checks for different architectures. I may be handling the scenario completely wrong, so let me know if that is the case, or if this is a duplicate.

As a simple example, suppose we have two parameters to consider for a web script: member status (non-member, member type-A, type-B, type-C) and form submission/non-form submission. Forms may be submitted by both members and non-members. Currently, the script would ideally be split up as such:

Members (A, B, C)
    ->Non-Forms
    ->Forms
Non-Members
    ->Non-Forms
    ->Forms

...however, it could be set up the other way:

Forms
    ->Members
    ->Non-Members
Non-Forms
    ->Members
    ->Non-Members

I suppose this is a specific case, so there will be considerations for why you may or may not want to process forms before other tasks, etc. However, I am looking for the general criteria for deciding such architecture division schemes in the future, not considering special case with obvious considerations, so that I can figure it out for myself. (Note: Security is, of course, a concern in this situation so there is good cause to seperate member and non-member functionalities, which is something I might consider as an 'obvious consideration'. If you have anything you want to add for this case, though, I will be all eyes.)

Answer 1

The best way to design your software for this instance would be to do so from a Domain Model driven approach. Essentially design your domain model and relationships between entities in your domain model. Persistence, events, business logic, security, view and controller logic can all be determined after the fact.

Example:

• Submission: properties common between Form's and Non-Forms
• Person?: properties common between Members and Non-Members
• Form: Extends Submission, has reference to a Person, properties of a Form
• Non-Form: Extends Submission, has reference to a Person, properties of a Non-Form
• Member: Extends Person, properties of a Member
• Non-Member: Extends Person, properties of a Non-Member

Now that you have defined your domain model and relationships between them, it becomes the logical next step to consider other aspects of your design. What are the clearly defined behaviors of a Non-Form over a Form? Define these behaviours in code. What business logic should execute on the event of submission of a Form? Code it. Security can be engrained of course, you consider behaviors that differ between a Member and a Non-Member as part of your business logic. Of course don't forget to thoroughly unit test all of your application behaviors.

The most important thing in your design is to DEFINE your domain model, only then should you consider behaviors.