In Fowler's Domain Model Pattern, through OO, you model your business. This creates a lot of object dependencies and objects become less reusable. Fowler also brings up the issue of special cases where the view needs some data, do we add that data to the domain model and if so, how do we integrate it?
A strong domain model seems to get you into trouble and causes your objects to be unusable outside of it's original intended application.
I'm kind of lost as to how to properly define a domain model or if it's really used by other developers. Also, AOP seems to be increasing in popularity which makes an AOP domain model a better solution-- it would promote finer grained objects and externalize object relationships to aspects.
Any opinions or experiences with business domain models and how you successfully implemented them?
I don't agree with you
because i think domain model is designed for more reuseable,why do u think it cause more dependency？
Domain Model make BO can be reused by many kinds of ORM product or JDBC.
Here's an example, you have accounts, but on a page you need to display the district and region managers for that account, do you add them as properties or do you create manager objects and query all of that useless data to get the manager names? I just seems like a waste to me.
I work in an environment with lots of concepts that could be rendered as objects but their behavior/state varies between applications, where do I draw the line? Do I instead create a domain model that is 'view' driven instead of business driven?
Here's an example, you have accounts, but on a page you need to display the district and region managers for that account, do you add them as properties
This is the way I do it, my DTO's (Data Transport Objects) map 1-1 with my domain objects i.e. database tables, I have an additional get/setPropert method for each DTO to transport additional data to the view.
As I'm code generating the DTO's from the schema this has worked well.
Ian PurtonWebsite and Server Monitoring
| Email Marketing
| Website Traffic Analysis
| Top 100 Album Charts
First off objects do not become less reusable. If a person object has a set of email address then thats because YOUR business model says so. So you can't just change it and while its nice to be decoupled and flexible the truth is that your business has rules and your domain model follows them. This has the plus side that it tells developers exactly what to expect rather than a more flexible there may be a relationship between person and address objects if you weave it through AOP. Its there. Express it.
Next, AOP has nothing to do with domain models. A domain model is the truest sense of object oriented design, i.e. objects model the "real" world or the world as a business or organization view it. Thats it. AOP has nothing to do with modelling and everything to do with moving around logic. Maybe you can clue me in to what an AOP domain model even is. Sounds like an oxymoron.