>
>
> http://www.infoq.com/articles/ddd-in-practice
This article seems somewhat biased ;) He's making a lot of big
assumptions about SOA that aren't necessarily correct. This is
especially true with large distributed systems.
> "'Anemic Domain Model' where facade classes (usually Stateless Session
> Beans) start accumulating more and more business logic and domain
> objects become mere data carriers with getters and setters."
This is correct. Anemic means no logic with data.
> Hm, With anemic model you dont need injeting into model because it is
> only data holder.
Yeah.
> In non-anemic model there is model, services (ejb3) and many helpers
> with support core model and have to be close it.
Not necessarily. In a non-anemic pattern the domain model _is_ the
service. If you invoke a method on it the logic to fulfill that method
is part of the domain class. You can abstract the logic out into an
EJB (eeck - yes even with EJB3), but that's just an anemic proxy. The
domain object is doing little more than encapsulating a client call:
// Anemic
CatService cs = ...;
Cat cat = ...;
cat = cs.fix(cat);
// DDD
Cat cat = ...;
cat.fix();
public class Cat {
private final CatService cs;
private boolean isFixed = false;
@Inject public Cat(CatService cs) {
this.cs = cs;
}
public void fix() {
isFixed = cs.fix(this);
}
}
These are essentially the same in my book. I think what a lot of true
DDD and non-anemic folks are looking for is this:
// DDD
Cat cat = ...;
cat.fix();
public class Cat {
private final EntityManager em;
private boolean isFixed = false;
@Inject public Cat(EntityManager em) {
this.em = em;
}
public void fix() {
isFixed = true;
em.persist(this);
}
}
The code to change the state and save it to the database (or whatever
else is required) is part of the domain object itself.
Both of these DDD approaches encapsulates the state transition within
the cat, but state can be really nasty sometimes and you have also
lost the state of the cat prior to it being fixed unless you clone it
in the client code. Anemic model can fix this situation easily. Plus,
in a distributed system, if I'm passing around a non-anemic Cat, the
fix method might not be guaranteed to work if the remote CatService
isn't reachable or the EntityManager can't connect to the database
from that server. Therefore, the contract is broken. This means you
need an on-the-wire representation of the Cat (SDO, XML, value-object,
transfer-object) and a DDD representation inside the tiers of the
system. This requires some data translation between the transfer-
object and the DDD once the remote server receives the message.
I generally like to think that data and logic should be put as far
away from each other as possible. It doesn't necessarily bloat the
services code anymore than the domain would be bloated. Additionally,
I can have multiple ways to "fix my cat" without writing multiple
domains and they all work on the same data object. That's pretty nice.
This means you can go discover services for "fixing" cats based on the
types and you get a lot of other benefits.
>
> So when you create model and on next time client require you to invoke
> service (without injecting you cant invoke service from model, unless
> as parameter for method model) and you will have to move implemented
> funtionality from Model/Helpers to Services which ends Anemic model
> (all logic are in services).
There are a number of DDD frameworks that will fix this for you using
constructor AOP and other concepts. But in vanilla Java, yes, this is
an issue unless the DI container always creates instances of your
domain.
> In bussiness system there is many abstraction in core system:
> connection to ldap, db, xml, many factories, authorization,
> optymalization like caches, views, builders, kontrolers, managers
> sessions and many other. I think support for this abstraction like IoC
> close to core system it will be added value to system. Guice configure
> system with defaults and in tests or during intergration with other
> system you can ovverride some system policy (example for ldap).
Not sure I follow this bit.
-bp
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"google-guice" 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/google-guice?hl=en
-~----------~----~----~----~------~----~------~--~---
