Contract-First SOA: Designing Business Domain: WCF

Question

I am building a completely new system using WCF. I am going to use Contract-First Approach for a service which is to be built based on Service Oriented concepts. I have a se

Answer 1

Before you figure this part out, you need to decide what your clients are going to get from each service method call. Does the client need a FixedAccount/SavingsAccount, or does it really just need an AccountSummary?

If the method (like the one in your example) just returns AccountSummary, then one simple way to do this is to add a method to BankAccount that creates the AccountSummary. Then when you want to return something (no matter what type of account it is, but assuming your two accounts inherit from BankAccount), you just do this:

return someAccount.ToSummary()

Some people will tell you that it's not "pure" in the sense that you're BankAccount class now knows about your AccountSummary, but personally I've always found it easier to work with. If you don't like that, tools like AutoMapper can do this pretty effectively as well (as was mentioned in the other answers).

If you're returning some kind of derived class and not the actual class itself, there's no way to get around mapping it somewhere (if you use AutoMapper or write something yourself). The only way to avoid having to do any mapping is to return BankAccount itself, and that is not recommended for a service because internal changes to the class can affect the service. It's easy to remember that now, but it's also easy to forget about it in 3 years when another developer is doing maintenance. Mapping also only sends across the service things that you explicitly tell it to, so again it helps avoid mistakes that leak data.

The content of BankAccount.ToSummary() is pretty simple

public AccountSummary ToSummary()
{
    AccountSummary s = new AccountSummary();
    s.AccountNumber = AccountNumber();
    s.Balance = Balance()
    return s;
}