It looks like you're describing an <a href="http://en.wikipedia.org/
wiki/Anemic_Domain_Model">anemic domain model</a>.

The account service should perform all the operations on accounts, by
loading account domain objects and then calling methods on these
objects to implement the operations. The service should do little
other than orchestrate the loading of accounts and then delegating to
methods on them. Udi's article which you quoted gives an example of
this. Ideally the service should make a single call to a domain object
for each domain operation.

You shouldn't have a SystemImplementationService.

On Oct 21, 10:53 am, Wayne Douglas <[email protected]> wrote:
> I've asked this 
> (http://stackoverflow.com/questions/3985893/soa-wcf-dissecting-the-sys...)
> question in relation to this topic, any help would be appreciated :)
>
> -------------------------->8---------------------------------------
>
> I'm building a system which will have a few channels feeding different
> clients (MonoDroid, MonoTouch, Asp.Net Mvc, REST API)
>
> I'm trying to adopt an SOA archetecture and also trying to adopt the
> persistence by reachability pattern 
> (http://www.udidahan.com/2009/06/29/dont-create-aggregate-roots/)
>
> My question relates to the design of the archetecture. How best to split the
> system into discreet chunks to benefit from SOA.
>
> In my model have a SystemImplementation which represents the an installation
> of the system iteself. And also an Account entity.
>
> The way I initially thought about designing this was to create the services
> as:
>
>    - SystemImplementationService - responsible for managing things related
>    to the actual installation itself such as branding, traffic logging etc
>    - AccountService - responsible for managing the users assets (media,
>    network of contacts etc)
>
> Logically the registration of a new user account would happen in
> AccountService.RegisterAccount where the service can take care of validating
> the new account (duped username check etc), hashing the pw etc
>
> However, in order to achieve persistence by reachability I'd need to add the
> new Account to the SystemImplementation.Accounts collection for it to save
> in the SystemImplementation service automatically (using nhibernate i can
> use lazy=extra to ensure when i add the new account to the collection it
> doesn't automatically load all accounts)
>
> For this to happen I'd probably need to create the Account in
> AccountService, pass back the unsaved entity to the client and then have the
> client call SystemImplementation.AssociateAccountWithSystemImplementation
>
> So that I don't need to call the SystemImplementation service from the
> AccountService (as this, correct me if I'm wrong - is bad practise)
>
> My question is then - am i splitting the system incorrectly? If so, how
> should I be splitting a system? Is there any methodology for defining the
> way a system should be split for SOA? Is it OK to call a WCF service from in
> a service:
>
> AccountService.RegisterAccount -->
> SystemImplementation.AssociateAccountWithSystemImplementation
>
> I'm worried i'm going to start building the system based on some
> antipatterns which will come to catch me later :)
>
> -------------------------->8---------------------------------------
>
> Cheers
>
> w://
>
>
>
>
>
>
>
>
>
> On Wed, Oct 20, 2010 at 7:14 PM, Thiago Alves <[email protected]> wrote:
> > Consider the following example:
>
> > e.g.: consider an user with a list of blogs:
>
> >             var user = session.Load<User>(1);
> >             user.OwnedBlogs.Add(new WebLog { Title = "My blog #1", Creator
> > = user });
> >             session.Update(user);
> >             session.Flush();
>
> > This code works but the user is actually loaded from the database (I guess
> > that's because a property of the user instance is accessed thus the proxy
> > loads the entity instance).
>
> > This other piece of code works just as expected:
>
> >             var webLog = new WebLog { Title = "My blog #2", Creator = new
> > User { ID=1 } };
> >             session.Save(webLog);
> >             session.Flush();
>
> > ... but in my domain model the User entity is an aggregate root for the
> > WebLog entity, so I would like to insert a new WebLog through the User
> > instance.
>
> > The relationship between User and WebLog (virtual public IList<WebLog>
> > OwnedBlogs { get; set; }) is mapped as a bag, with cascade="all" and
> > lazy="true" (lazy="extra" yields the same results)
>
> > Is there something conceptually wrong in the examples above? Is there
> > another way to accomplish what I want to do?
>
> > Thanks in advance
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "nhusers" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> > [email protected]<nhusers%[email protected] 
> > >
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/nhusers?hl=en.
>
> --
> Cheers,
>
> w://

-- 
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en.

Reply via email to