Do you model Physical Things or Process?

PHP
1

I am trying to build an e-commerce site from scratch and getting very confused about what to model when creating classes.

One approach is to model Physical Things, for example:

  • User
  • Address Book (collection of Addresses)
  • Address
  • Wish List (collection of Products)
  • Products
  • Catalog (collection of Products)
  • Shopping Cart (collection of Products)
  • Order (consists of User, Addresses, Shopping Cart Products, OrderDetails, Payment)
  • Payment
    and so on…

Then again, another approach would be to model Behaviors/Processes, for example:

  • User
  • RegistrationService
  • AuthenticationService
  • ShoppingService
  • CheckoutService
  • ReturnService
  • UserProfileService
    and so on…

At least one person has told me that the first approach isn’t a good idea and that it is too rigid. He said, “Your design should mimic how things work in the real-world and mimic the process things follow. Don’t feel you have to copy your backend database structure!”

I can see taking either approach, but don’t know which is better, OR if there are even other architectural approaches?! :-/

People tease me that I have “analysis paralysis”, but this is pretty serious stuff, and not something where you can go down one path and then later on just change your mind!

My end-goal is simplicity. Because if I can’t understand things, then nothing else matters!!

I do want to design and program something that is scalable and maintainable and that I can be proud of, but I also need to be practical and come up with something I can get “out the door” PRONTO!!!

Now would be a good time for some Object-Oriented gurus (or Architects) to swoop in to save me!!! :blush:

Sincerely,

TomTees

2

Hi…

Processes or physical things? Probably neither, but occasionally both :).

One book you should probably read is the Rebecca Wirfs-Brock object oriented design one: http://www.amazon.com/Object-Design-Roles-Responsibilities-Collaborations/dp/0201379430/ref=sr_1_1?ie=UTF8&s=books&qid=1288520399&sr=1-1

You are basically after roles, but you have to tease those out toward the end of the process. You won’t have a really good answer for your particular problem until you are past the first implementation and into maintenance mode :(.

Anyway, taking just method names for the moment (these can be lifted as events from your use cases) look to group then into things that do stuff (roles). It’s roles you are after. These may well be physical things and they may even be processes.

There are some object/pattern catalogues (some by Martin Fowler) which you can read to get some ideas.

I can never figure this stuff out on a first try. I either have to build a prototype first over a couple of days, or I just have to evolve it as I go (by putting in the design refactorings at the last possible moment).

yours, Marcus

3

I think one way to help you make your decision is to first decide on the requirements and priorities of your website and then go from there

For example:

Is speed/performance of your website your number priority ?
or
How easy and fast you will develop the site?

Generally speaking closer you keep your classes to “Physical Things” easier is to reuse later. This way you are generalizing things more.

While being closer to “Behaviors/Processes Things” faster your application will be because there is less generalization happening.

4

I usually do a flow chart for each screen a user would see and when a request is sent/submitted to and from the server. Then I look at each area and determine where I could reuse code.

5

Well said!!!

I am trying to build an e-commerce site from scratch and getting very confused about what to model when creating classes.

Check out Magento. Its harder to some degree but the time you spend on making your own, you can start with a multi-million dollar platform and make so much more.

6

The problem is that these types of decisions can’t be thrown in the same bucket, on a generic basis. In some cases it best to use one methodology over the other. A Product is a perfect example of what most likely will be modeled after a “real-world” object. On the other hand, register is an action which would probably be better suited being represented as such.