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

For approach one, consider using a tool like AutoMapper rather than implementing the mapping manually. Could save you a great deal of pain. AutoMapper

Answer 2

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;
}

Answer 3

First of all - you need to understand if you really need full-blown SOA.

SOA basically means that every operation is going through service that decouples our system from other system/s. In rare cases (in case application grows extra huge) - one part of system from another.

Will your application "talk" with any other application?

If not and you are just building monolith website, free your mind and cut that SOA bullcrap. Otherwise you will end up with useless abstraction layer.

That is the only way you can apply 2nd approach because you can't decouple domain model completely without mapping it to something else.

---

In case there really is a need for SOA - we must encapsulate, hide from outer world our domain model. That means - there must be some kind of mapping from our model to DTOs.

Is there any article/tutorial that explains how to map AccountSummary DTO to FixedAccount/ SavingsAccount

Mapping itself isn't complex idea. Here's one simple way to map objects:

class AccountSummary{
  public string InterestingThing {get; set;}
  public string AnotherThing {get; set;}
}
class AccountSummaryMapper{
   public static Map(BankAccount a){
    return new AccountSummary{
        InterestingThing=a.SomethingSomething,
        AnotherThing=a.Something.Else.ToString()
      };
   }
}
var accountSummary=
  AccountSummaryMapper.Map(myBankAccount);

This might seem ineffective. Object-to-object mappers like Automapper can help. Go through tutorial, it should be good enough to get you going. Idea ain't hard - you create Maps, tell Mapper about them on application start and then use Mapper to Map your objects by given configuration.

---

Also - think about mapping direction. Good object oriented code usually means that you either ask questions or tell object to do stuff. Objects shouldn't know about inner workings of other object responsibilities.

In analogy - it is bad for parents to complete their child homework because child won't learn anything and parent will be burdened with unnecessary work. Instead - parent should force child to work on his own.

Mapping AccountSummary directly to BankAccount and re-setting its state is like doing homework. There shouldn't be need for such a mapping. Instead - tell BankAccount to BankAccount.DoHomework(pencil, copybook, someStrongWords).

---

develop the business domain

You do not develop business domain. You develop domain model which is just a reflection of business domain, made to solve particular problems.