Domain layer questions
Moderator: General Moderators
Domain layer questions
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...
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Domain layer questions
By delineate you mean what exactly?Is it good practice to delineate between services, entities, and values in your layering ( I assume yes? ).
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.Should this be reflected in your directory structure?
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.
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.I don't want to force myself into a linear way of doing things
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
# trace the shape ofPCSpectra wrote: By delineate you mean what exactly?
# 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
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 thoughYears back I argued that the PEAR/Zend convention of class names to directory path was bad practice..
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Domain layer questions
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?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
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/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_dalConsider 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.phpThose 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.
Cheers,
Alex
Re: Domain layer questions
I think bothPCSpectra wrote:You want to reflect that layering or relationship in the directory structure, or your asking whether you should or shouldn't?
Good pointPCSpectra 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...
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:Whether that organization is hierarchial is entirely up to the implementor.
heh? Why not?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.
Can you elaborate / mention specific pitfalls you encountered?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.
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: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
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: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 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 anglePCSpectra 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.But even if I didn't it's always fun to braind dump ideas or thoughts to help cement them in my own head.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Domain layer questions
I draw my decencies with red arrows
I know what you meant but that is the funniest typo I've seen all day...
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".
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
Eh, the essence of good design is not having your packages flash eachotherPCSpectra wrote:I draw my decencies with red arrows![]()
![]()
![]()
I know what you meant but that is the funniest typo I've seen all day...