Re: Avoiding Cyclic Dependencies in Domain Entities

sorry for the duplicate(ish) posting - there was quite a latency which 
tripped me up.
Dan

------------------------------------

RE: Avoiding Cyclic Dependencies in Domain Entities

Hey Greg/Dan/Aaron,

I sincerely appreciate your responses.

Greg:
Yes, your concepts are perfectly correct, I do not have a single method called ComputeAndCharge(),
(thought it would be simpler for others to understand my problem hence, had written the same)....in fact I
am a very strong supporter of the "High Cohesive, less Coupling" Principle.
The "Tell not Ask" principle was pretty interesting stuff....thnx 4 the same, if  you read this mail
further, you will know that the problem is deeper.

Aaron: Thnx for the Interface Solution, but that may not work in my case.

Dan: Wow, That was pretty good, but the problem would still remain, since internally the Penalty Rate
Changer Interface can only get a Rate from the Loan Account. Let me just Clarify the Following Points and
elaborate on a few things further,

Effectively I need to 3 things to calculate Penalty Interest ie PNR/100, Principal, Rate and Term

1) Loan Account (Entity)
 		- contains Penalty Rates
 		- Also contains behavior to charge a Late Penalty - calls a LoanPenalty.computeLatePenalty [Value Object]

2) Early Penalty Service (Value Object) called by the Transaction Service
		- contains behavior to charge a Early Penalty - calls a LoanPenalty.computeEarlyPenalty [Value Object]

3) Loan Penalty(Value Object)
		- It get Rates from Loan Account, Principal from Principal Repository and Term from Schedule Repository
		- Its purpose is to get the Information ie PNR and pass it to an Interest Calculator
		

RE: DDD and SOA

SV: Re: Do you allow that aggregates / entities get temporarily in an invalid state?

Hello Greg,

sorry for my late reply - I was on vacation ;)

--- In domaindrivendesign <at> yahoogroups.com, Greg Young
<gregoryyoung1@...> wrote:
>
> Push the changes together in a unit of work, don't change the domain  
> object directly...

I like this approch. Can you give a small example how you would
implement this?

Thanks

Matthias

------------------------------------

Re: SV: Re: Do you allow that aggregates / entities get temporarily in an invalid state?

matthias.kampen wrote:
> 
> 
> Hello Greg,
> 
> sorry for my late reply - I was on vacation ;)
> 
> --- In domaindrivendesign <at> yahoogroups.com 
> <mailto:domaindrivendesign%40yahoogroups.com>, Greg Young
> <gregoryyoung1@...> wrote:
>  >
>  > Push the changes together in a unit of work, don't change the domain
>  > object directly...
> 
> I like this approch. Can you give a small example how you would
> implement this?

The UnitOfWork pattern is implemented in Qi4j(.org), like so:

// Create UoW
UnitOfWork uow = uowFactory.newUnitOfWork();

// Get references to some Entities
// Entities are ALWAYS accessed with the context
// of a UoW
SomeEntity some1 = uow.getReference("id1234");
SomeEntity another1 = uow.getReference("id5678");

// Invoke domain model
// This may change the state of properties
// and associations
some.doStuffWith(another1);

// Complete the UoW
// This takes the recorded changes and
// sends them to the underlying EntityStore
uow.complete();
----

Since Entities are always associated with a UoW it is trivial to 
register what gets done and then send it to the database on complete(). 
The physical transaction only occurs on complete(), so there is also no 
problem at all with having "long running" UoW's, which is most often an 
impossibility with transactions (i.e. there is no notion of "timeout" on 
UoW's).

Another win of using UoW is that if complete() fails due to validation 
errors (yes, it is possible to register validation callbacks which 
trigger on complete()), those errors can be corrected and complete() can 
be called again. This is not the case with transaction.commit() (AFAIK), 
which typically has to be done again if the commit fails (correct me if 
I'm wrong here). If the UoW is mapped to a client dialog (ok=complete(), 
validation failure=don't close dialog), that kind of code becomes really 
easy to write.

If you want more details of the actual implementation of UoW rather than 
the usage, check the code of Qi4j, specifically UnitOfWorkInstance.java.

/Rickard

------------------------------------

Re: Should history information locate in domain?

As Jason observed, logging is not meant to be used by the end user -
that then is the indicator it is not to be considered part of a domain,
it's just a technical side-effect.

Version histories are for users to see, for point-in-time state
retrieval etc, very much like Martin Fowler's patterns on things that
change over time. So these are in the domain.

There is actually a third "level" of this, which is the undo-able unit
of work. User-level undo is clearly exposed to the end users and for
that reason quite likely part of a domain model. What it needs at the
technical level is version histories on all entities, plus a reference
to a unit of work identifier on all of those version records. The undo
feature could be exposed as a stack of user-level transactions (units of
work) that can be undone one by one, working from the top of the stack
only, although that would quickly conflict with user entitlements when
not all users have the same access rights to the data being processed.
So, as an alternative, it can be exposed as a compensation capability,
one where all the original modifications are reversed so that those data
elements that were modified back then come back to their pre-transactino
state. Any unrelated modifications to other data elements that happened
later in time would remain untouched.

--- In domaindrivendesign <at> yahoogroups.com, "jasonmeckley"
<jasonmeckley@...> wrote:
>
> What's the different of "history" object and the logging?
> depends on your definition of history and logging and how you intend
> to use this information.
>
> I see logging as a one way service to capture pieces of information
> about the state of the system. I can persist these log messages to
> somewhere and analyze them at a later point in time. These message
> are not use within the system. they are simply there for me to trouble
> shoot what did(n't) happen.
>
> logging is for developers/helpdeks. It's not meant to be used directly
> by the end user.
>
> I define History as a snapshot of of the entity at different periods
> in time. Usually when the state of the entity changes. I only keep
> the history around if it's required by the system. The client wants a
> customer change history report. Or when calculating commissions for a
> customer I need to know the state of the customer at a point in
history.
>
> --- In domaindrivendesign <at> yahoogroups.com, "calendarw" calendarw@
> wrote:
> >
> > --- In domaindrivendesign <at> yahoogroups.com, "moffdub" <moffdub@>
wrote:
> > >
> > > I dealt with this in my domain layer because it was an important
> > > concern for my client. Here is what I did:
> > >
> > > * one domain object that modeled the traditional entity
> > > * one domain object that modeled the value object "history
> > > information", like the User that had edited the entity, the
DateTime
> > > when they did so, and the Building in which they did so
> > > * one aggregate that contained the above two
> > > ______
> > > The views expressed here are mine and do not reflect the official
> > > opinion of my employer or the organization through which the
Internet
> > > was accessed.
> > >
> >
> > What's the different of "history" object and the logging? how to
> > aggregate it? any simple design of "history aggregate"? (I know
> > little of aggregation but I don't know how to do in this case)
> >
>

------------------------------------

SV: Re: Do you allow that aggregates / entities get temporarily in an invalid state?

--- In domaindrivendesign <at> yahoogroups.com, Rickard Öberg
<rickardoberg@...> wrote:
>
> matthias.kampen wrote:
> > --- In domaindrivendesign <at> yahoogroups.com 
> > <mailto:domaindrivendesign%40yahoogroups.com>, Greg Young
> > <gregoryyoung1@> wrote:
> >  >
> >  > Push the changes together in a unit of work, don't change the
domain
> >  > object directly...
> > 
> > I like this approch. Can you give a small example how you would
> > implement this?
> 
> The UnitOfWork pattern is implemented in Qi4j(.org), like so:
> 
> // Create UoW
> UnitOfWork uow = uowFactory.newUnitOfWork();
> 
> // Get references to some Entities
> // Entities are ALWAYS accessed with the context
> // of a UoW
> SomeEntity some1 = uow.getReference("id1234");
> SomeEntity another1 = uow.getReference("id5678");
> 
> // Invoke domain model
> // This may change the state of properties
> // and associations
> some.doStuffWith(another1);

In this case the methods you invoke could still lead to invalid object
states as you change the entity directly. Is there an example of Greg
Young's implementation?

> // Complete the UoW
> // This takes the recorded changes and
> // sends them to the underlying EntityStore
> uow.complete();

Thanks

------------------------------------

Re: SV: Re: Do you allow that aggregates / entities get temporarily in an invalid state?

matthias.kampen wrote:
> In this case the methods you invoke could still lead to invalid object
> states as you change the entity directly. 

Yes, that's the point, that within a UoW the state may be invalid, but 
at the end of a UoW the state is always validated.

/Rickard

------------------------------------

Re: Re: Do you allow that aggregates / entities get temporarily in an invalid state?

I use a unit of work in terms of messaging.

I represent all incoming operations as commands. These are optionally
put into a unit of work. Since everything is just simple commands, you
start running them. If it would put an object in an invalid state, the
object rejects the command. If you never get to commit you just throw
away all of your changes. This can be done in two ways depending on
how you want to handle concurrency and transactional purity.

If you are in a transactional situation you just throw away all of your changes.

The second way is to "undo" the piece of work that you did. A command
can return a command which is a [Compensating Action]. This is quite
useful when many systems are involved in a given unit of work and you
don't have transactional behaviors associated (integrating with other
systems without using 2pc etc). There is a great article on this here
http://www.eaipatterns.com/ramblings/18_starbucks.html

Cheers,

Greg

On Mon, Sep 1, 2008 at 9:24 AM, matthias.kampen
<matthias.kampen <at> yahoo.com> wrote:
> Hello Greg,
>
> sorry for my late reply - I was on vacation ;)
>
> --- In domaindrivendesign <at> yahoogroups.com, Greg Young
> <gregoryyoung1@...> wrote:
>>
>> Push the changes together in a unit of work, don't change the domain
>> object directly...
>
> I like this approch. Can you give a small example how you would
> implement this?
>
> Thanks
>
> Matthias
>
> 

--

-- 
It is the mark of an educated mind to be able to entertain a thought
without accepting it.

------------------------------------

Re: DDD and SOA

Based on the feedback I'm getting it seems as if the general 
interpredation is that SOA and DDD is a nice match that can very well 
coexists and enricht each other.

I'm having a bit of practical question as to how these should be 
paired tougheter.
Does anyone have an nice example (code or diagrams) of how these are 
technices are combined?

Hopefully someone has something that they would like to post.
If not I will se if I can come up with a live-cycle example that can 
function as a discussion base.

Regards, TEK

--- In domaindrivendesign <at> yahoogroups.com, "trondeirikkolloen" <trond-
eirik@...> wrote:
>
> Hi folks
> 
> Service Oriented Development (SOA) is a very hot topic these days.
> The hot potato of SOA is to supply groups of functionality in a way 
> that is reusable between traditional barries as applications, 
> networks, operating system and development languages.
> 
> It seems for me as SOA is used in several contexes. In the start I 
> tought as Services in SOA as a web service. During time I, and 
others 
> I think, is viewing the Service in SOA as group of functionality 
> might be utilized between layers in the same system, and not 
> nessesarly only between different systems.
> 
> When defining that you have a Service at some location, that will 
> also imply some special restrictions, as standardized data 
transfer, 
> fault isolation and more. For example, it is not possible for a 
> domain object to travel trought a service.
> 
> What I'm wondering about is what you are thinking about the concept 
> of SOA vs. the concept of DDD?
> Are they a perfect match fullilling each other?
> Are they excusion concepts, meaning that if you use DDD you cannot 
> use SOA?
> Are they solving/attaching different part of the problem domain?
> Are they solving the same part of the problem domain?
> and so on...
> 
> What do you think?
> 
> Best regards, Trond-Eirik

------------------------------------