• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Junilu Lacar
  • Rob Spoor
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Jesse Silverman
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Piet Souris
  • Frits Walraven

question on implementation in domain driven design

 
Ranch Hand
Posts: 308
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by manuel aldana:
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.



I think your being lead astray by the implementation assumptions that you are making during design. Two observations:

If your domain is account management then "account" is a model element because you are doing things to or with the account. However you typically don't login to that "account" because you are using the administrator account to make the modifications.

If your domain is something else entirely then the act of "logging in" isn't central to the domain model. You would typically already have passed the authentication and authorization phase if you have access to the model. So the authorization process is irrelevant to the domain model.

Business logic can be usually be found in three places:
  • Entity (preferred, after all everybody should know their own business)
  • Repository (if there are some special infrastructure requirements)
  • Service


  • Now if there is some special authorization that an entity needs to obtain that could then be modeled through a service.

    Applying Domain Driven Design and Patterns (amazon US) is a good DDD �by example� book if you can put up with a .NET implementation.
    Domain Driven Design Quickly is available in exchange for your eMail address � then of course there is the Domain Driven Design site.
     
    manuel aldana
    Ranch Hand
    Posts: 308
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    first of all, thanks for you answer.

    following to ensure, that i got you right.


    If your domain is account management then "account" is a model element because you are doing things to or with the account. However you typically don't login to that "account" because you are using the administrator account to make the modifications.


    so you mean that all the business logic which does not modify/work on the data (entities) is not part of the domain model. but then how does consider domain driven design these dynamic processes?
     
    Peer Reynders
    Bartender
    Posts: 2968
    6
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I'm not sure that we a talking about the same thing here.
    Under most circumstances "logging in", i.e. the process of being authenticated and then authorized isn't considered "business logic". In most cases that process has already been completed by the time you get into contact with the domain model.
    In the case where you have a public (anonymous) portion and a secured portion of the model, you would most likely model an authentication/authorization service that can provide certain model elements with an authorization handle that is required to obtain access to the secured parts of the model. However in some circumstances it may simply be easier to separate the public and secured model entirely, especially if they provide "a different view of the world".

    Originally posted by manuel aldana:
    data (entities)



    In the context of DDD Entities are not to be confused with entities from entity modeling:
    Have a look at Domain Layer dependency confusion for some of the definitions.
    [ May 31, 2007: Message edited by: Peer Reynders ]
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    reply
      Bookmark Topic Watch Topic
    • New Topic