Suggestions on creating Factories for big domain objects

We have a big object graph with lot of properties and behavior in it. We are currently revisiting our domain and we are going to go the DDD approach. But we are in need of a suggestion from you experts on how to go about creating Factories for our big domain model.

Problem

We cater to multiple geographies like US, Canada, Spain, Chile, Brazil, UK etc. As it is evident each one of then have differences in addresses, names ((last name, surname 1, surname 2 etc)), phone numbers, national IDs etc. At a high level the domain model looks like this

1. a Transaction can have multiple Subject's
2. a Subject has Name, Address, TelephoneNumber, NationalID
3. a Subject can be a ConsumerSubject or a BusinessSubject
4. a ConsumerSubject has a PersonName while a BusinessSubject has a BusinessName
5. a Address can be a USAddress, UKAddress, CanadianAddre开发者_StackOverflow社区ss, ChileAddress etc and the same way there can be geography specific subclasses for most of the domain objects (where applicable)

For every new request we need to create this entire set of objects properly populated in a valid state. We can use the Abstract Factory pattern to have Geography specific factories like USTransactionFactory, CanadianTransactionFactory etc.

Required Suggestion here

How to pass-in the parameters to create these objects. Taking Address as an example

1. Should we have a createXXXAddress(...) method for each geography that takes in city, state etc as input arguments? This means that we need to have createUSAddress(...), createCanadianAddress(...), createChileanAddress(...) etc

2. OR should we just have one createAddress(Address addr) method that just takes Address object and let the client create the appropriate geography specific Address object? E.g

   SpainAddress spain=new SpainAddress(); spain.setMuniciplaityName(...);

3. OR should we have a separate AbstractFactory for each of the significant domain objects? For e.g USAddressFactory, UKAddressFactory etc

Required Suggestion here

Is there a necessity to create DTO's for this? I am thinking just pass the domain to presentation layer but maintain immutability by enforcing read-only view of the domain. For e.g each domain object will implement two interfaces: ReadOnlyAddress, MutableAddress. This was inspired by how joda-time.

Any other suggestions and criticisms are welcome.

1. Should we have a createXXXAddress(...) method for each geography that takes in city, state etc as input arguments? This means that we need to have createUSAddress(...), createCanadianAddress(...), createChileanAddress(...) etc
2. OR should we just have one createAddress(Address addr) method that just takes Address object and let the client create the appropriate geography specific Address object?
3. OR should we have a separate AbstractFactory for each of the significant domain objects? For e.g USAddressFactory, UKAddressFactory etc

I would definitely not recommend option 1: it would result in binding client code to specific geographies, probably requiring lots of switch/if-else statements scattered all over the place, and code changes in each of those whenever geographies are added/removed - the exact problem polymorphism was meant to resolve.

I am not quite clear about the exact difference between your options 2 and 3, but my first approach would be to use some sort of a GeographyFactory to produce part(s) or the whole of the object graph you describe here. Thus clients would call a single createAddress method but the methodf itself would be polymorphic.

Whether the factory would be dependency injected directly to the client or used (partly) transparently in the background similar to a locale in C++ depends on the circumstances - both approach may be fine.

Is there a necessity to create DTO's for this? I am thinking just pass the domain to presentation layer but maintain immutability by enforcing read-only view of the domain.

With regards to addresses, I would try to get away by immutable objects only - if an address changes, you can just create a new object and throw away the old one. Note that addresses are rarely first-class entities, but rather surrogate value objects (i.e. have no identity of their own). But of course, a lot depends on the details of your object-relational mapping solution and the DB schema.