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
Model partitions
Moderator: General Moderators
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Model partitions
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"
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"
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Model partitions
Of course. That's just basic code reuse, single use, DRY, etc. It does not matter what the class is used for.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?
(#10850)