Page 1 of 1

Model partitions

Posted: Fri Jan 14, 2011 10:09 am
by alex.barylski
In complex domain models a single model class will quickly grow unweildy. Assuming you already divide your application into units/packages/components like User, Cart, etc. Do you further still partition your package model into separate distinct sub-models (for lack of a better word), reflective of their individual intent?

For instance, I occassionaly break mine into:

Crud.php
Events.php
Selectors.php

DDD is something I have been reading up on and following for a while and they seem to advocate partitoning complex models, what do you do specifically?

Cheers,
Alex

Re: Model partitions

Posted: Fri Jan 14, 2011 9:22 pm
by josh
Draw the method names. Start with class members on the low level methods on the bottom left hand side of the paper. Move outwards and write the low level methods, circle the method names. Move outwards towards higher level methods. Draw arrows from high level methods to the low level methods/members that they call. You'll notice obvious groups, that's where you break them up. For example with my year/make/model application there was a model "Level" that encapsulated makes/models/years. It used to have methods like getCurrentLevel(), getNextLevel(), getNextLevelsFrom($level), etc.. These all went into one group on my little sketch diagram, so I found a new home, sprouted a class called "the schema" and moved those methods there.

There's also partitioning for different context, an Order object may have a bunch of methods used in one context, a bunch used in another, and some methods used in both contexts. That becomes a superclass, and two sub-class, one for each context. I do this little diagram sketch & break up the code only after the class becomes too big to manage. I got the idea from "working effectively with legacy code"

Re: Model partitions

Posted: Sat Jan 15, 2011 6:17 pm
by Christopher
alex.barylski wrote:In complex domain models a single model class will quickly grow unweildy. Assuming you already divide your application into units/packages/components like User, Cart, etc. Do you further still partition your package model into separate distinct sub-models (for lack of a better word), reflective of their individual intent?
Of course. That's just basic code reuse, single use, DRY, etc. It does not matter what the class is used for.