Anti Corruption Layer

[esuyer]

Thanks for the folks at domaindrivendesign.org for putting this
document out there

http://domaindrivendesign.org/practitioner_reports/hu_ying_2007_01.html#
Anticorruption

I found it to be very valuable. I have a few questions in terms of
implentation. Any info is much appreciated!

1. In your case study, was all communication implemented via events?
So for example, if there was a GetOrders method that pulled data from
the legacy system. Would this have been implemented via events as well?

2. Did the anti corruption layer run in the same app domain as SPOT?

3. Where does the OrderManager class reside? In SPOT?

[pslh93]

1. I don't fully understand the first question. All communication from
SPOT domain objects to the TBSExport is implemented using .Net event.
As the communication is always one-way from SPOT to TBS (the legacy
system), we never had a GetOrders method to retreive information from
the legacy system. This is because SPOT doesn't depend on the legacy
system. Assumeing SPOT does need to retrieve information from TBS, the
dependency becomes two-way and I am not sure if we can still use the
event to do the retrieving.

2. Yes, otherwise we would have to use .Net remoting (remote events).

3. In SPOT. The OrderManager and other managers (ContractManager,
CustomerManager, etc) are also Spot domain objects. They are similar
to the "Service" class described in Eric's DDD book. Managers are
responsible for controling business work flow, dispatching messages
and coordinating with different types of "core objects" like Order and
Contrat.

Post by esuyer
Thanks for the folks at domaindrivendesign.org for putting this
document out there
http://domaindrivendesign.org/practitioner_reports/hu_ying_2007_01.html#
Anticorruption
I found it to be very valuable. I have a few questions in terms of
implentation. Any info is much appreciated!
1. In your case study, was all communication implemented via events?
So for example, if there was a GetOrders method that pulled data from
the legacy system. Would this have been implemented via events as well?
2. Did the anti corruption layer run in the same app domain as SPOT?
3. Where does the OrderManager class reside? In SPOT?

[Edward Suyer]

Got it, and thanks for the response

RE: As the communication is always one-way from SPOT to TBS (the legacy
system), we never had a GetOrders method ...

Let's say for the sake of discussion that you were to implement a two-way
communication mechanism and that you needed a GetOrders method to pull the
legacy data ... would you continue to use events? Using events seems to
continue to give you the blissful ignorance that the anti corruption layer
exists. But something feels unnatural to me about getting data this way.
What if someone came along and added a second subscriber to GetOrders for
example. What do you think? Would you move to a traditional client-server
communication here? Or across the board?
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.17.13/1211 - Release Date: 1/6/2008
11:57 AM

[huying_ca]

Events can still be a good option for the two-way communication case.
Suppose legacy system TBS needs to send a message back to SPOT for a
status change (e.g. an incoming payment is reconciled in TBS), a
possible implementation could be:

1. legacy system writes out info to database

2. a dispatcher (in a dedicated thread) polls the database
periodically. When a new message arrives, dispatcher raises an event.

3. SPOT object (in this case, likely PaymentManager) subscribes to the
event and responds accordingly.

PaymentManager doesn't know where the messages come from and how, it
only responds to a "Payment Reconciled" event. For a different type of
payment the same event might come from SPOT domain itself, but the
same handler is used for the processing logic.

Ying

Post by Edward Suyer
Got it, and thanks for the response
RE: As the communication is always one-way from SPOT to TBS (the legacy
system), we never had a GetOrders method ...
Let's say for the sake of discussion that you were to implement a two-way
communication mechanism and that you needed a GetOrders method to pull the
legacy data ... would you continue to use events? Using events seems to
continue to give you the blissful ignorance that the anti corruption layer
exists. But something feels unnatural to me about getting data this way.
What if someone came along and added a second subscriber to

GetOrders for

Post by Edward Suyer
example. What do you think? Would you move to a traditional

client-server

Post by Edward Suyer
communication here? Or across the board?
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.17.13/1211 - Release Date: 1/6/2008
11:57 AM

[Dan Bergh Johnsson]

Hi fellow DDDers

For quite some time I have been thinking about how to use DDD ideas,
mindsets, and approaches to adress security issues. To start somewhere
my college John Wilander and I started discussing the OWASP Top Ten list
of common application security flaws (he is quite involved in the OWASP
community).

This very day it all came to the point where we decided to start talking
about "Domain Driven Security", and to kick of each of us (yeah, both
two) have written a blog post on how we view the issue - he from an
OWASP/AppSec perspective, and I from a DDD point of view.

John:
[http://owaspsweden.blogspot.com/2009/09/domandriven-sakerhet-domain-dri
ven.html]
Me:
[http://dearjunior.blogspot.com/2009/09/introducing-domain-driven-securi
ty.html].

I would be really interested to hear if there are other people out
there, and on this list, that have had similar thoughts or experiences.

Yours

Dan


Dan Bergh Johnsson, Omegapoint AB | http://www.omegapoint.se
0709 - 15 88 43 | http://dearjunior.blogspot.com


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

[Tapio Kulmala]

Hello Dan!

Great posts. I really enjoyed reading them. I mostly agree what you and John
wrote. Data validation on the domain level is not enough. The bigger problem
is how to validate business rules on each integration point. The data could
be valid but both sides must have a common understanding on what the data
really means, what they can do with it and what they are expected to do with
it.

Tapio

On Wed, Sep 16, 2009 at 11:50 PM, Dan Bergh Johnsson <

Post by Dan Bergh Johnsson
Hi fellow DDDers
For quite some time I have been thinking about how to use DDD ideas,
mindsets, and approaches to adress security issues. To start somewhere
my college John Wilander and I started discussing the OWASP Top Ten list
of common application security flaws (he is quite involved in the OWASP
community).
This very day it all came to the point where we decided to start talking
about "Domain Driven Security", and to kick of each of us (yeah, both
two) have written a blog post on how we view the issue - he from an
OWASP/AppSec perspective, and I from a DDD point of view.
[http://owaspsweden.blogspot.com/2009/09/domandriven-sakerhet-domain-dri
ven.html]
[http://dearjunior.blogspot.com/2009/09/introducing-domain-driven-securi
ty.html].
I would be really interested to hear if there are other people out
there, and on this list, that have had similar thoughts or experiences.
Yours
Dan
Dan Bergh Johnsson, Omegapoint AB | http://www.omegapoint.se
0709 - 15 88 43 | http://dearjunior.blogspot.com