On Nov 7, 6:23 pm, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
> >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
Thanks for reply both. I have read disccusion and have thoughts.
I think Model could be:
1) a well defined wire format (serializable, viewable)
2) good start point to make decision with inheritance instead of "if"
in services
I think using model only for sending data is wasting time and forcing
to duplicate code. I many situations one class is using in many
aspects (send data, view data, populate date) and model has much more
granularity in opposite to services.
Cat
- chooseShampoo() { if (virusStrategy.needAddtionalCheck())
{ ... } ... }
BrownCat
- chooseShampoo() { ... }
BlackCat
- chooseShampoo() { if (fortuneTeller.isAnimalOK(this) and if
(usaVirusStrategy.checkInFbi(this)) { ... } ... }
Earlier I didn't know that Guice sometimes creates proxy so I create
even serializable objects in guice. Now I will use GuiceFacade in
Model like GuiceFacase.inject(this).
In services similiar problem ends with many "if" (services are not so
modular)
CatService
- if (cat instance of BrownCat) {
...
} else if (cat instance of BlackCat) {
if (fortuneTeller.isAnimalOK(this) and if
(usaVirusStrategy.checkInFbi(this)) { ... } ...
} else {
if (virusStrategy.needAddtionalCheck()) { ... } ...
}
Cat is serializable entity so hibernate get from database rigth
inheritance (blackcat or other specjalization).
I dont want using many "if". One solution is above, so model has
access to interfaces (!) of services, kontrollers, views and how these
interfaces are implemented is outside decision (choosen could some
exception on client, but on server not).
Other solution to OO without "if" which comes to my mind:
CatService
- selectorService = InheritanceSelelctor.choose(cat,
ShampooSelector.class) { Class.forName(ShampooSelector.getName() +
cat.getClass().getSimpleName());
selectorService.chooseShampoo(cat);
ShampooSelectorCat implements ShampooSelector (service)
- if (virusStrategy.needAddtionalCheck()) { ... } ...
ShampooSelectorBrownCat implements ShampooSelector (service)
- ...
ShampooSelectorBlackCat implements ShampooSelector (service)
- if (fortuneTeller.isAnimalOK(this) and if
(usaVirusStrategy.checkInFbi(this)) { ... } ...
What do you think ? ;>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
