Re: Domain logic is mainly handled in Services?

Re: Domain logic is mainly handled in Services?

RE: Re: Repository access

Re: Can UI Layer access Entities?

Yes, actually I didn't express my thought clearly. the userDomain 
appeared in my code stands for the meaning of "domain for user 
management", which is a facade for user management. In the 
userDomain.CreateUser function, the user would be constructed by the 
factory and be persisted by the repository.

I think I perfer Matthew Adams's opinion. UI elements SHOULD NOT 
access Domain Entities directly. This because entities are not of 
Anemic Domain Model, which means that there would be some domain 
related methods or functions in entities. If UI elements call the 
entities directly, it seems that the UI can access the domain logic 
directly, this breaks the "encapsulation" attribute of the domain 
layer.

So I think DTO would be a better solution here. 

--- In domaindrivendesign <at> yahoogroups.com, "david_torontonian" 
<david_torontonian@...> wrote:
>
> Unfortunately none of these approaches are really DDD(more close 
to 
> Anemic Domain Model). These are the issues:
> 
> 1.In DDD (unlike Anemic Domain Model) we don't separate data and 
> behaviors so there wouldn't be User and UserDomain. A single 
entity 
> would contain data and related behaviors.
> 
> 2.Repository persists the entities not domain object. So 
> userDomain.CreateUser is not correct
> 
> In my view, your code should look like this:
> 
> User user = new User();
> user.Username = "abc";
> user.Password = "def";
> UserRepository userRepository = new UserRepository();
> userRepository.Add(user);
> 
> --- In domaindrivendesign <at> yahoogroups.com, "acqy_sunnychen" 
> <acqy_sunnychen@> wrote:
> >
> > Can Entities be accessed by User Interface (Presentation) Layer?
> > 
> > I'm using ASP.NET
> > 
> > For example, When user clicks "Register" button on the Web UI, 
> there 
> > are two approaches listed below. Which one is correct?
> > 
> > 1. Create a User Entity object and pass it to the Create User 
> > business procedure:
> > 
> >  User user = new User();
> >  user.Username = "abc";
> >  user.Password = "def";
> >  UserDomain userDomain = new UserDomain();
> >  userDomain.CreateUser(user);
> > 
> > 2. Just pass the primitive data types to the business procedure 
and 
> > create the User object inside the business procedure:
> > 
> >  UserDomain userDomain = new UserDomain();
> >  userDomain.CreateUser("abc", "def"); // User object will be 
> created 
> > inside this call
> > 
> > 
> > I'm new to DDD and I don't know how to handle such situation. 
Could 
> > anyone help me?
> >
>

 

What's the relationship between SOA and DDD?

Firstly let me say sorry for my "stupid" question. Because I'm a newbie 
on SOA and DDD fields.

SOA is very hot in these years. But I think no matter what SOA is, it 
cannot escape from the Domain Logic. So I think SOA is mainly about 
enterprise application architecture and DDD, which pays close attention 
to the Domain Model and Domain Logic, is the basis of SOA.

 

Re: What's the relationship between SOA and DDD?

I think it's important to explore this question, it's certainly not 
a stupid one.
I've also posted the question at the following...
http://tech.groups.yahoo.com/group/domaindrivendesign/message/7005

SOA does cover enterprise application concerns, but it does so by 
making business logic, business interfaces, and business messages a 
first-class IT asset that is managed, monitored and maintained that 
like other IT infrastructure.  DDD is an excellent way to model and 
implement these business centric assets.

The problem I have with looking at SOA and DDD is that DDD seems to 
apply a lot of object oriented approaches (which I think are 
excellent IMHO) that do not necessarily translate well to SOA.  
Objects with robust self encapsulated behavior being one of them.
Jeff
http://agileconsulting.blogspot.com/

--- In domaindrivendesign <at> yahoogroups.com, "acqy_sunnychen" 
<acqy_sunnychen@...> wrote:
>
> Firstly let me say sorry for my "stupid" question. Because I'm a 
newbie 
> on SOA and DDD fields.
> 
> SOA is very hot in these years. But I think no matter what SOA is, 
it 
> cannot escape from the Domain Logic. So I think SOA is mainly 
about 
> enterprise application architecture and DDD, which pays close 
attention 
> to the Domain Model and Domain Logic, is the basis of SOA.
>

 

Should DTOs maintain the object relations?

Should DTOs maintain the object relations? For example if I have two 
Entities: User and Forum. A user could be the moderator of several 
Forums, and a Forum of course may have several moderators(users to 
manage this forum). This bidirectional relationship could be maintained 
within the domain model but if I create the DTOs for these entities, do 
I still need to maintain such relation? It seems a little redundance to 
do so.

 

Re: Should DTOs maintain the object relations?

Another post that seems to be related to my question is here:

http://geekswithblogs.net/opiesblog/archive/2006/08/18/88396.aspx

please also take a reference to this post.

Thanks a lot!

--- In domaindrivendesign <at> yahoogroups.com, "acqy_sunnychen" 
<acqy_sunnychen@...> wrote:
>
> Should DTOs maintain the object relations? For example if I have two 
> Entities: User and Forum. A user could be the moderator of several 
> Forums, and a Forum of course may have several moderators(users to 
> manage this forum). This bidirectional relationship could be 
maintained 
> within the domain model but if I create the DTOs for these entities, 
do 
> I still need to maintain such relation? It seems a little redundance 
to 
> do so.
>

 

Re: Should DTOs maintain the object relations?

On Tue, Mar 4, 2008 at 7:46 AM, acqy_sunnychen <acqy_sunnychen <at> yahoo.com> wrote:
> Should DTOs maintain the object relations? For example if I have two
>  Entities: User and Forum. A user could be the moderator of several
>  Forums, and a Forum of course may have several moderators(users to
>  manage this forum). This bidirectional relationship could be maintained
>  within the domain model but if I create the DTOs for these entities, do
>  I still need to maintain such relation? It seems a little redundance to
>  do so.

If the clients of DTO have no use for such a relationship, I don't see
why you would have to implement it. In my experience, even when I have
bidirectional relations in domain (and I try to avoid it, if
possible), in most cases it doesn't need to be reflected in DTOs, so I
don't do it.

 

Re: Asynchronous Repositories