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.


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.
//save it to the repository.

4 Answers 4


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.
//save it to the repository.

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.

  • This seems sensible, but how does it align with DDD principles? Nov 8, 2012 at 16:10
  • The Fare acts as an aggregate root, FareInformation is part of its aggregate. Instead of creating a FareInformationRepository, you manage the aggregate through its Root. Nov 8, 2012 at 17:54
  • Where does the ChangeFee object come from? Nov 8, 2012 at 17:56
  • It's a Subclass of FareInformation. Thus the Fare only knows that it holds a collection of FareInformation object. The details of the logic behind those objects are embedded directly in them. Nov 8, 2012 at 18:29
  • So it's not my case, because I never setup additional information in my app, instead i just load the information from server (call server api).
    – tikhop
    Nov 8, 2012 at 18:40

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.


  • Thx for advice, i think too that the service is a better choice.
    – tikhop
    Nov 9, 2012 at 12:04

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.

  • How does this fit into the DDD model? Nov 8, 2012 at 23:33
  • 1
    The DDD model (I'm referring DDD as described in Eric Evans' book) pretty thoroughly describes the responsibility of the Repository, as they differ from the responsibilities of the various services. In my reading of it, it's pretty obvious where the Repository responsibilities end...
    – Eric King
    Nov 8, 2012 at 23:38

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.

  • The problem with this is that a fare object must now have knowledge about all sorts of external things like flight schedules, fuel costs, airplane type, first-class upgrades and the like. Do you put all that machinery into the Fare object, or does it make more sense to provide a separate service that acts on that fare and sets it to the proper value? Also, how does this all fit within DDD? Nov 8, 2012 at 16:12
  • Usually, You will want to plug a Service Layer on top of your Domain model layer to handle this kind of tasks and avoid having bloated Domain model entities and violate SRP. My answers arn't related with DDD in particular.
    – Beton
    Nov 9, 2012 at 8:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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