hi folks,
i am having a question about domain driven design. as long as i (roughly) understood, domain driven design tries to map the business closely to a domain model to tackle down misunderstandings between requirements and implementation.
in all examples i have seen so far domain models closely connect to persistent layer (e.g. databases), i.e. each model element somehow is obviously planned to be persistend. but what about the business stuff, which is difficult to map to a model and is merely "pure" business functionality.
(simple) Example: account management.
-following is obvious: Profile relates to Account and make sense to be persisted.
-following is not clear: how would i express a Login Action in a domain driven design. surely it is a part of account management's domain, but in my view it is not a model element, it is pure business logic, which does not make sense to persisted, because it is a workflow/session action.
to solve my misunderstandings, maybe someone has got links/literature hints, which explain how an emerged domain driven model would be mapped to a layered application technically. as i stated above i relate domain model close to persistent layer and am not sure how to map things in a seperate layers (view+business).
or maybe domain driven design does not focus on a layered architecture at all and encapsulates all inside model elements (which makes maintaining a bit tricky in my point of view...)? further more this way the implementation gets quite difficult, because frameworks (ejbs,
struts, hibernate, grails etc.) often mandate to seperate business logic, view and model elements.
many thanks!