These are great questions, doubt you're a noob.

My $.02
Your security model(Authentication and Authorization) are cross cutting concerns
and should be visible to all layers where this is a concern. I've never
personally seen an authentication svc. If not handled automatically by the app
platform (asp.net:windows auth,form auth, etc) it's handled by a hand made forms
auth (user,pwd) module, shared by all layers where there is a public entry
point. Do you mean to write an authentication provider and forego the available
ones? Authorization is the same deal. The Ent Lib is targeted guidance tailer
made to address these design decisions. Maybe too bloated for some, it's at the
very least a great way to examine reference implemenations.

Your Service layer should address repositories directly, IMO. Repositories
should not know of one another. The services which consume repositories can and
will have multiple repositories and use them to compose and persist your
domain's data. If you break this rule, your layers will cease to be layers..
Just verticals poking through one another.

I prefer factories to any other means of composition. This is the overly
simplified version of what will work for you.
Should be something like
IEmployeeSvc svc = IoC.Resolve<IEmployeeSvc>();
Employee employee = svc.GetEmployee(guid); // load from persisted state
.... inside svc
GetEmployee(guid){
return new Employee(guid){
// init other stuff in here
EmployeeComponent1 = _emprepository.GetStuff(guid)..
EmployeeComponent2 = _empOtherRepository.GetStuff(guid)..
EmployeeComponent3 = _empOtherOtherRepository.GetStuff(guid)..
}

// if you like object and collection Initializers :)

}

// modify employee in View/Presentation/Controller/Etc
IoC.Resolve<IEmployeeSvc>.SaveEmployee(guid); or
IoC.Resolve<IEmployeeSvc>.SaveEmployee(Employee e);


That's the way it works for many people. This can be mocked, faked, tested all
interface driven. Seems too simple? People like M. Fowler and other big leaguers
will tell you to keep it simple and as complexity increases many "clever"
solutions spin out of control and become smelly as some put it.


--- In altdotnet@yahoogroups.com, "chevronboyde" <samuel@...> wrote:
>
> Hi All
>
> DDD Noob here needing some clarity on DDD. I am looking at an asp.net mvc web
application and have a few questions.
>
> 1) Where would actions like AuthenticateUser(username, password) exist?
> Does this exist as a method of the User entity i.e.
User.Authenticate(username, password)
> Should it exist as a service to the Domain
UserService.AuthenticateUser(username, password)
>
> 2) When persisting entities, should I be using a service/facade or using the
Repository directly:
> User user = new User("Joe Soap");
> IoC.Container.Resolve<IUserRepository>().SaveUser(user);
> or something like UserFacade.SaveUser(user) which in turn uses the repository.
>
> Previously my tiers were as follows:
> Web - asp.net
> BusinessLogic - facade and business objects with methods like SaveUser
> DataAccess - encapsulated data access using ent library
> Common - config info, services etc
>
>
> I am trying to understand how this translates with DDD with a simple example
of authenticating a user and saving a user to the db. Curently using nhibernate,
castle windsor and rhino
>
> Hope that was clear
>
> Sam
>