Domain Driven Design: Handling complex entities with many states and relations (Real Estate)

I don't do PHP, but I can suggest how to model your classes:

Clients and Roles

1. Create an interface (or abstractclass) called Role. Role has areference back to a Client

2. Inherit the following classes fromRole: Owner, Purchaser, Buyer, Tennant, Investor

3. For each of these concrete Role classes,extend the members as necessary (e.g. a Tennantmay have MonthlyRent)

4. Add a list of Roles to your Client.Whenever a new Role is added toClient.Roles, the Role shouldreference the Client

The important part: Most of your classes should reference the individual Role object, instead of the Client. You can access the Client via the Role.

Property states and transitions

1. Create an interface (or abstract class) called PropertyEvent. Add a timestamp property to it called OccurredAt.

2. Inherit the following classes from PropertyEvent: Appraisal, Listing, Sold, Withdrawn

3. For each of these concrete PropertyEvent classes, extend the members as necessary (e.g. anAppraisal will have an associatedAppraisedBy?)

4. Add a list of PropertyEvents to yourProperty. Whenever the state changes,create the appropriate Event and addit to Propery.History.

The important part: This is the notion of a Domain Event. This technique will automatically provide a history of the state changes for the Property.

Note that I haven't focused on entities, or Aggregates, or Value Objects. You can work those out as you get a better feel for your model.

Hope that helps!

First of all don't make yourself too crazy. One of the reasons object oriented programming is generally considered a good idea is you can try something and then refactor as your understanding of the problem domain increases.

For the entities you've identified that have various "states" study the State Design Pattern - with the wrinkle in your situation that an entity can have more than one State. Determine what entities are Aggregate Roots - sounds like Property and Client - and due to the complex relationship treat each in a separate Bounded Context. Then I think your instinct is correct, pass the outsider as a Value Object into the Bounded Context of the other to get results out (most likely through a Service Object).

For the Clients, consider giving them roles. The roles can be separate entities and a Client entity can have many of these roles.