DDD - Domain Model Problem

I have i discussion with a partner we have this scenario:

**Publishers root entity 
Advertiser root entity**

Each of those entities share common info : Email, BillingAddress, NormalAddress, sex, SSN, etc.

I have decide: Person Entity with a Value object Address and rest of properties. This way if i want to access a specific info about a Person (email, sex, dateofbird) i dont have to go through publisher or ad开发者_Python百科vertiser root entities to get it (treat Person as an aggregate root).

Sample: **Person.BillingAddress.Address1 :
        Person.BillingAddress.Address2 :
        Person.BillingAddress.POBOX :
        Person.Email :
        Person.Sex**

My teammate propose to to do it using abstract class, advertiser and publisher inherits from Person abstract class in order to have all common properties.

What is the best way to do it?. If you have one please guide us.

Thanks, Pedro de la Cruz

---

I think that you are right. Inheritance just make sense when the behaviour is common (some thing is a kind of other thing), then Person isnt a kind of OTHER THING just because the properties are similars. It isnt code reuse.

---

You should favour composition over inheritance.

Your design is better because otherwise if at some point you need to introduce something else in this hierarchy (e.g make your root entities AuditableEntity) you won't be able to do so (unless your language supports multiple inheritance - which is bad).

---

I don't care for inheritance in this case - I think it's brittle.

I would prefer an approach based on composition and Roles. An Administrator Role might wrap a Person object and have all the special attributes and behaviors associated with the Role.

---

I would think Advertiser and Publisher should inherit from Company, and a Company should have a collection of Contacts (or Persons in your case).

Technically Company could have a collection of Branches.

Then each Branch can have an Address, and each Contact (Person) can have an Address.

---

@ Scott what is the problem in inheriting from person ?

@Tim how inheritance fails here ?

Let Person be abstract class and Advertiser and Publisher as concrete class. In this way Advertiser will have common properties, same for publisher, now we can pass person.

Advertiser is Person. Publisher is Person. I prefer inheritance

---

My 2 cents...

As I am reading your question, it seems the physical person is not a part of your model. Your model deals with Publishers and Advertisers.

First. I think the physical person (or company) has to live in a separated "Tier Referential" domain, that can transform into a "Tier or Partner Repository".

Second. As your model needs Publishers and Advertisers, I think it should be the responsibility of the DAL (and the repository but in a smaller manner), to define and create these entities. The DAL is the only place you should have the physical person item (as it is not an entity in your model, I called it "item"), and you should take care of isolating it from the model. The physical person has to stay on the data-side, as it is implied in the construction plan of the Publishers and the Partners entities. Refining and hydrating those entities should be in the repository.

I think you should not have a "Person" class in your model, I think you should have it "beneath" the repository, invisible from your model.

---

(warning - overly simplistic)

Inheritance in this case fails the "is a" test..

normally you would ask "is" my class "a" <whatever> or does it "have" a <whatever>

---

Well I know its been years and i am too late to answer here.

1. This is not a problem of DDD domain modeling. This is Object Oriented Domain Modeling. So the question itself is very misleading.

Few years back putting the word DDD would hardly make any difference, but in microservices era the importance of DDD has suddenly risen. So to all the Microservices enthusiasts this question would create a Lot of Confusion.

DDD Domain Model MUST NOT BE Confused with OO Domain Model