Page 1 of 1

Domain layer questions

Posted: Fri Dec 05, 2008 4:45 pm
by josh
Is it good practice to delineate between services, entities, and values in your layering ( I assume yes? ). Should this be reflected in your directory structure? What is a generally accepted best practice for going about this? What about responsibility layering? Should I just show it in my UML diagrams or should my actual design show it? I plan to eventually have 100+ packages.. is it "bad" to make sub-packages? I am paranoid to do it because won't it couple the sub-packages and make them less cohesive with other packages? I don't want to force myself into a linear way of doing things...

Re: Domain layer questions

Posted: Fri Dec 05, 2008 5:47 pm
by alex.barylski
Is it good practice to delineate between services, entities, and values in your layering ( I assume yes? ).
By delineate you mean what exactly?
Should this be reflected in your directory structure?
Years back I argued that the PEAR/Zend convention of class names to directory path was bad practice...I can't remember my exact arguments but essentially I felt there was a sense of source fragility at the interface level of the classes, basically being tightly coupled to directory.

I have since change my mind and use that convention for my entire class source tree. While the class name is difficult to change as it requires relocating the file, it is a far less common occurence (in my development) than time spent trying to find a class location on the file system given only the name, so I favour the coupling.

Secondly, the file structure is equally important in terms of organization your source code, just as using modular classes and properly named methods. They all play a part in describing your problem domain.
I don't want to force myself into a linear way of doing things
You using terms which could be interpreted in such a way they are wildly different from your own, so I find this difficult to answer or understand.

Having class names reflect the directory structure will couple the class to the directory. Coupling is something we as developers need to just deal with...we try and minimize it (like dependencies) but for the most part we strive to make them clean and easily understood.

This convention does tend to get int the way with "dynamically modular" architectures, where you want to drop in mini-applications, which cannot usually comform to your application convention, due to the fact you are essentially nesting an application within an application -- if I understand your questions/concerns correctly?

This is one the problems I have encountered myself. In these instances I wonder if it would not be easier to allow classes to reside in arbitrary directories, as opposed to the 1:1 relationship they share with directories in the case of Zend/PEAR.

I really depends on what you consider the bigger time waster.

1. Finding classes quickly by having the class name map directly to a directory
2. Adding "components" into you application dynamically and having an extendable system

Re: Domain layer questions

Posted: Fri Dec 05, 2008 6:48 pm
by josh
PCSpectra wrote: By delineate you mean what exactly?
# trace the shape of
# trace: make a mark or lines on a surface; "draw a line"; "trace the outline of a figure in the sand"
# delineated: represented accurately or precisely
# describe in vivid detail

Meaning, my finders and services are in a separate layer from the classes for the objects they find, should my directory layout reflect this layering and if so I'd like to see an dumbed down example of how this is done
Years back I argued that the PEAR/Zend convention of class names to directory path was bad practice..
I use zend style names to map class names to path/files. I'm talking about convention to delineate larger architectural idioms then on the unit level though

Re: Domain layer questions

Posted: Fri Dec 05, 2008 7:35 pm
by alex.barylski
Meaning, my finders and services are in a separate layer from the classes for the objects they find, should my directory layout reflect this layering and if so I'd like to see an dumbed down example of how this is done
I'm repeating what is already known, but for the sake of conversation, lets say service locators and such are by their nature in separate layers, so I understand that. Your models use these 'services' such a locale objects?

You want to reflect that layering or relationship in the directory structure, or your asking whether you should or shouldn't?

IMHO conceptual layering and file system structure (while similar in many ways) I think represent two different paradigms of software development. File systems are innately strutural, whereas layering is typically conceptual and more flexible...

The OSI layers for example, should have little knowledge of those under them (except the next in line) and certainly shouldn't have knowledge of those above it. Of course in real life, perfect layering is a pipe dream and coupling does exist.

A structured file system on the other hand doesn't really dictate (implicitly or explicitly) any relationship(s) it's main focus in organization. Whether that organization is hierarchial is entirely up to the implementor. I personally have tried organizing my file system so base classes were root files and sub classes were in sub-directories...that didn't work well.

Likewise I have tried having the facade/interface reflected as root files and the derived classes located in sub-directories. While this worked a little better, it still not perfect.

Personally I keep my classes in an organization like:

Code: Select all

...
models/
view/
services/
Being in a single directory one might think they are 'layered' unfortunately I don't have direct control over the direction in which those files are displayed so I cannot say this one comes first, this one second, etc.

The work around (ie: Linux) is to use a convention that allows control over the ordering by prefixing file names with numbers like:

Code: Select all

01_models
02_dal
I think in this case...it works awesome (because it represents execution order not layering per se) but at the source code level trying to express layering using the file system would be a struggle to say the least.

Consider the example I just gave with models...

If models relied on a data access layer I might reflect that setup in the directory structure like so:

Code: Select all

models/
  account.php
  person.php
  dal/
    account.php
    person.php
Now the file system indicates the relationship implicitly but it's core focus is still organizational. What this might lead you to believe is that all sub-layer dependencies of the model should be within the sub-directories like the DAL. But what about service objects like Locale? Or Authorization?

Those are system services and should obviously not be stored in the model directory. They are IMHO best left for their own directory 'services'.

I find mysef constantly asking these kind of questions, so it's certainly of interest to me, that is assuming I understood your question in the first place. :P But even if I didn't it's always fun to braind dump ideas or thoughts to help cement them in my own head. :)

Cheers,
Alex

Re: Domain layer questions

Posted: Fri Dec 05, 2008 7:55 pm
by josh
PCSpectra wrote:You want to reflect that layering or relationship in the directory structure, or your asking whether you should or shouldn't?
I think both
PCSpectra wrote:IMHO conceptual layering and file system structure (while similar in many ways) I think represent two different paradigms of software development. File systems are innately strutural, whereas layering is typically conceptual and more flexible...
Good point
PCSpectra wrote:Whether that organization is hierarchial is entirely up to the implementor.
I guess thats what I'm asking, I realize its a matter of preference as is everything, but what are the tradeoffs I need to consider before partially commiting to a methodology?
PCSpectra wrote: I personally have tried organizing my file system so base classes were root files and sub classes were in sub-directories...that didn't work well.
heh? Why not?
PCSpectra wrote: Likewise I have tried having the facade/interface reflected as root files and the derived classes located in sub-directories. While this worked a little better, it still not perfect.
Can you elaborate / mention specific pitfalls you encountered?

PCSpectra wrote:If models relied on a data access layer I might reflect that setup in the directory structure like so:

Code: Select all

models/
  account.php
  person.php
  dal/
    account.php
    person.php
I guess that's what I'm asking, what is this called? And when do you know when to make "dal" it's own package, I mean theoretically anything can call the data access layer, putting it in a package makes it explicit, right?
PCSpectra wrote:What this might lead you to believe is that all sub-layer dependencies of the model should be within the sub-directories like the DAL. But what about service objects like Locale? Or Authorization?

Those are system services and should obviously not be stored in the model directory. They are IMHO best left for their own directory 'services'.
Or a shared kernel, or a conceptual responsibility layer.. which is my original question, what are the trade offs between the different ways of explicitly vs implicitly specifying these in the file structure? Should it be done even?
PCSpectra wrote:I find mysef constantly asking these kind of questions, so it's certainly of interest to me, that is assuming I understood your question in the first place. :P But even if I didn't it's always fun to braind dump ideas or thoughts to help cement them in my own head. :)
I agree. I draw my decencies with red arrows from package to package on the whiteboard so they stand out, I try to make as little red as possible, whenever I start getting crossing lines I erase everything try attacking from a different angle

Re: Domain layer questions

Posted: Fri Dec 05, 2008 8:25 pm
by alex.barylski
I draw my decencies with red arrows
:lol: :lol: :lol:

I know what you meant but that is the funniest typo I've seen all day... :P

The other week I was reading some web site for a Flash IM component I want to use in an upcoming project...

Instead of turnkey instant chat solutions...the page was actually selling "turkey instant chat solutions". :lol: :lol:

I should have probably notifed them of the error but I thought that was just to funny...PHP Instant Chat or something I can't remember the product now...but I don't believe they were native English speakers, so I should take it easy on them...damn funny though. :)

ANyways...I'm working on a project right now but will need a break in a bit and will cntinue this dissucssion.

Cheers,
Alex

Re: Domain layer questions

Posted: Fri Dec 05, 2008 9:36 pm
by josh
PCSpectra wrote:
I draw my decencies with red arrows
:lol: :lol: :lol:

I know what you meant but that is the funniest typo I've seen all day... :P
Eh, the essence of good design is not having your packages flash eachother :mrgreen: