Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm struggling to find guidance on integrating various applications, usually based on a Domain Model architecture. The applications often expose and consume each others WCF services, but this tends to be done in a rather hap-hazard way. I'm quite certain that the domain should not access another applications services, but where should they be consumed from? UI, Application layer? Data Layer? All I've read about SOA seems to contain theoretical information about what makes a service, but nothing about how to actually implement it in code. And what if I need to return/query on a join between two entities in two systems? Many resources suggest denormalising data into the calling system, and updating using messages, but should messaging and WCF be combined in the same system?

I've read Enterprise Application Integration but it still leaves me with many questions. What are good resources/code samples for integrating domain model systems?

share|improve this question
    
You should read Domain Driven Design by Eric Evans. –  Falcon Sep 30 '11 at 21:03
    
Read it! It doesn't concentrate too heavily on integration, and it's mostly theoretical. –  Paul T Davies Oct 2 '11 at 8:15
    
@PaulTDavies M. Fowlers 'Enterprise Application Architecture Patterns' is also good reading on the topic, and there are lot of samples (including code) in it. –  πάντα ῥεῖ Nov 9 '13 at 12:19
add comment

1 Answer

up vote 3 down vote accepted

There is no problem that cannot be solved by adding a layer of abstraction, except for having too many layers of abstraction.

If you have four domains from four disparate apps, and you are attempting to integrate their functionality or data into one app, then use the four domains, with an extra layer on top to handle interop between them; each domain or SOA layer will talk to your new layer, which will facilitate passing data across the borders of each domain as well as up to the application, so the domains can remain unaware of each other as they are in their original apps, and the application layer has one point of contact so it doesn't care how many separate domains lie underneath. Exactly how you architect this is dependent on the nature of the domains and SOAs you are integrating.

If you think of your app in an n-tier fashion, e.g. UI/Application/Domain/DAL/Data, and don't want to think of this new layer of abstraction being its own tier, then consider it as part of the Application layer. However, it is usually best explained as a new tier, "Interop", between Application and Domain layers.

Do be aware of the exception to the rule in the first sentence. Avoid architecting "lasagna code", having so many layers of abstraction between tiers that even simple changes like adding a field require you to spend your day drilling down through all the layers of abstraction. Data, mapping, domain field, service layer (client and server), DTO, application layer, Controller, UI... You could easily end up touching a dozen objects just to add a checkbox to a form if you over-separate. Also avoid the "God Object" when implementing your interop layer; it can be tempting to create one object that can give any object to any other object, but consider Factories and Converters with smaller scopes that are managed by supervisor objects (again, no problem you can't solve with another layer of abstraction...).

share|improve this answer
    
Cheers Keith, can you point me in the direction of any books/resources for this? Code sample especially would be helpful. –  Paul T Davies Oct 2 '11 at 8:24
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.