Micro Models

I stumbled mentally on the conclusion that the easiest way to do OOP in a team environment where modeling, DDD, UML, etc. aren't regimented (on a side note, I have yet to see a place where it truly is regimented uniformly), is to use this notion of "Micro Models" -- mini-domain models set up quickly under tight encapsulation constraints (Facades for pulling data out and interfaces for creation).

For example, given a new requirement to produce a report listing some options for a decision maker, one may come up with an algorithm to produce such a report using various inputs factored for timing, weighting etc. In this case the inputs would be your domain objects yielding as message responses the results of internal calculations based on their own object graphs and object-specific notions of the algorithmic factors. There could even be objects that model the algorithm itself and its outputs, such as "Iteration," "Plan", etc.

The object model, i.e. the "Micro Model," would NOT use a repository, DAO, ORM, or anything to indicate that it is not alone in this world. This is where Micro Modeling departs from DDD IMO. Instead, the Micro Model is spawned once and only once by a DAO or collection of DAOs that essentially provide to the client of the Micro Model the seed object, which the client and/or the facade can use to interface with the model. So the DAO -- itself an abstraction here, the implementation of which is injected and could make use of other DAOs, ORMs, services etc. -- knows about the Micro Model (the seed objects anyway), but the Micro Model does not know about the DAO. Note, I'm not saying Repository because that is a DDD concept that implies the domain can access the Repository, which is see as defeating encapsulation and also conrtradicts OOP principles that state that objects and behavior go together; and also ironically seems to contradict DDD itself which from what I gather preaches that objects should represent the domain -- and what does say a RestaurantRepository represent in the domain? A Restaurant represents a restaurant, but a RestaurantRepository?? This is what I would consider to be a leaky abstraction...

See also:
"Bounded Contexts" in DDD