.net - 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 service operation that returns a bank account details of a user. The account can be of type “FixedAccount” or “SavingsAccount”. I have designed the service as follows.

[ServiceContract]
interface IMyService
{
[OperationContract]
AccountSummary AccountsForUser(User user);
}


[DataContract]
class AccountSummary
{
 [DataMember]
 public string AccountNumber {get;set;}

 [DataMember]
 public string AccountType {get;set;}
}

This much is fine.

Now, I need to develop the business domain for this service. I can think of two options (any new approach is always welcome)

1) Approach 1: Come up with a BankAccount base class. The specialized classes derived from it are “FixedAccount” and “SavingsAccount”. The BankAccount will have an method as Transfer(string toAccount). This becomes our familiar & effective OOAD. This involves mapper for mapping between AccountSummary DTO and FixedAccount/ SavingsAccount domain classes.

2) Approach 2: Without using mapper translation layer.

Questions

1) Suppose I am using approach 1. Is there any article/tutorial that explains how to map AccountSummary DTO to FixedAccount/ SavingsAccount domain classes based on the AccountType value in DTO (conditional mapping) ?

2) How do I achieve the task in approach 2 ?

---

READING:-

1. http://www.soapatterns.org/service_facade.php

2. SOA architecture data access

3. Designing services and operations in WCF

4. WCF Data Contract and Reference Entity Data?

5. When does logic belong in the Business Object/Entity, and when does it belong in a Service?

Answer 1

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.