Hello Domain-Driven Designers,

In the Service Layer chapter I contributed to Martin Fowler's Patterns of
Enterprise Application Architecture, I tried to draw a distinction between
"application" logic and "domain" logic. It just seems to me that there is often
logic required in an application that is not "of" the problem domain, but rather
"of" the application itself. For example, an enterprise application's
requirements might call for notifying interested stakeholders (via email), and
notifying integrated applications (via messaging or whatever) of business
transactions that have occurred within the application, as part of the
application's response to whatever stimulus consummated the business
transaction. I don't regard this kind of notification logic as "domain" logic.
It doesn't really have anything to do with the problem domain -oriented behavior
of the abstractions from the problem domain that you've chosen to reify in your
application's code. Therefore I contend it doesn't "fit" on domain objects, and
putting it there has negative consequences on type dependency graphs, domain
object reusability, etc. I contend it belongs instead in the service layer,
which is "higher" than the domain layer, and whose job is to coordinate the
application's response to such stimuli. Does anyone care to take up a
discussion of this topic?

Thanks,
RandyStafford
----

ApplicationLogicVsDomainLogic is mentioned on: ThreadView