DDD: Service or Repository

Question

I am developing an app in DDD manner. And I have a little problem with it.

I have a Fare (airline fare) and FareRepository objects. And at some point I should load additional fare information (from a server, call server api) and setup this information to existing Fare.

I guess that I need to create an Application Service (FareAdditionalInformationService) that will deal with obtaining data from the server and than update existing Fare or put the business logic in Fare object. However, some people said me that it is necessary to use FareRepository for this problem.

I don't know wich place is better for my problem Service or Repository.

UPDATE:

After researching, I came to the conclusion, that the better place for fetching additional Fare information is a service like (AdditionalFareService).

The code would look something like this:

//create service for fetching fare information
AdditionalFareService service = new AdditionalFareService();
//get a fare by Id
Fare fare = fareRepository.GetById(myFareId);
//Obtain information from service
var fareInformation=service.getAdditionalInformation(fare)
//Add it to the fare.
fare.AddInformation(fareInformation);
//save it to the repository.
fareRepository.Save(fare);

Answer 1

I'm assuming that the FareInformation provides details about a given Fare (e.g. special terms and conditions, change fees, etc.)

You need a way to create and save a FareInformation in order to associate it with the Fare. In this case, I'd say provide methods on the Fare that does it for you.

The API would look something like this

//get a fare by Id
Fare fare = fareRepository.GetById(myFareId);
//Create a change fee object.
var fareInformation=new ChangeFee(new UsdCurrency(50.00d))
//Add it to the fare.
fare.AddInformation(fareInformation);
//save it to the repository.
fareRepository.Save(fare);

Note that I'm sending a ChangeFee object and not a FareInformation object. FareInformation is a base class in a hierarchy. I'm relying on the O/RM to map the hierarchy to a database structure for me.

Answer 2

Let aside the patterns for a moment, and look for the responsibilities you have to divide across the system.

• Get to the server and retrieve Additional Information for fares
• Associate the retrieved info with existent Fare object
• Update Fare objects with additional info

For sure, the first responsibility has little in common with FareRepository duties (database/orm mapping of Fare objects). Putting them together would harm your system cohesion.

The second one is clear an responsibility to put into Fare objects.

The third one is an responsibility of FareRepository, since it has to handle update/retrieval of Fare objects in any state (with ou without additional information associated). Even if the additional information deserves an specific class.

So, just looking to responsibilities and cohesion, it doesn't make much sense to use the repository to access the server. The service pattern is a good choice to encapsulate the first responsibility.

Regards.

Answer 3

You say you're doing this is a DDD manner, right? Then the FareRepository should be concerned with persisting your data (exposing the Fare data as if it were an in memory collection).

If all you have to do is modify some simple properties and save, then using just the repository is fine.

If there is certain business logic that must be considered when updating the Fare classes with the additional information, then that business logic should be in a service.

One of your comments indicated that there are all sorts of 'external' considerations like flight schedules, fuel costs, upgrade, and such to deal with when adding the additional information. This almost mandates that you should have a service coordinate the process.

Answer 4

As far as I know, developing your application in DDD manner you are working on Domain Model pattern (http://martinfowler.com/eaaCatalog/domainModel.html).

If it is your case, such logic should be encapsulated IN your domain object (Fare). The Fare object itself should expose methods that work ON the domain object and manipulating its state accordingly.