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)

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


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


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


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

  • In this case, there is no object for a non-member, only a member. A non-member is simply a visitor to the webpage and no information is recorded, while members are stored in a table. Also, for submissions, there is only a page click (hyperlink) and a submission of a form. I didn't really consider a page click to be a submission (although I guess it is), and is considered the 'normal' processing mode since it uses the URL only. So, in this case, is there a point to creating the entities PERSON and SUBMISSION? Should there only be Member and Forms?
    – user58446
    Jan 3, 2015 at 13:34
  • You have to think about it in an OOP way. Non-Member might not be a persistable entity but it is still an entity that influences the BEHAVIOR of your application. Even though they have no authenticated status in your ststem they still have some kind of Guest session going on, so you probably should have temporary state about this guest entity.
    – maple_shaft
    Jan 3, 2015 at 16:43
  • Considering Person and Submission, a Person is an entity yes, however is Submission really an entity? I would say it isn't. Submission is a behavior or event that is triggered by a Person, and Submission is done to a Form. A Submission is a defined behavior not an entity. This behavior is influenced by the current state of other entities.
    – maple_shaft
    Jan 3, 2015 at 16:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.