CODEWITHSUNDEEP
wcfweb-servicesdomain-driven-designsoa
Lee Simpson
Lee Simpson

Reputation: 309

Approach to design service objects to be specific, or generic?

Scenario: Using a tiered approach with WCF services: business services returning domain / DTO objects to the client. Still in development so we can break the contracts.

Person object has first name and surname. Member object has tax file number and date of birth. This is because, in our domain, only members get tax file numbers and dates of birth. When getting data back from a service using this structure it is clear what attributes are applicable.

Now, we introduce another service that has a usage for person - lets say Employee. in this usage the person object requires the additional attributes tax file number, and date of birth.

What is the best way to proceed?

1) Treat the Person object as a generic Person and include all of the attributes. This maps the Person to a real world person, not necessarily based on usage. This means that services that return Persons will include tax file number and date of birth, even though they may not be relevant.

2) Duplicate the additional fields into Employee. This leaves Person as is, and keeps service calls specific at the expense of duplication.

3) Create another in between object called PersonWithDOBTFN that we inherit from for Member and Employee. This removes duplication, keeps things specific but introduces complexity.

I am really looking for a best practice approach to designing these objects.

Upvotes: 0

Views: 153

Answers (2)

Sisyphus
Sisyphus

Reputation: 4231

There is a problem with what you are doing - it breaks down under a variety of circumstances. The most obvious case immediately just from your brief example is if a person wants to be a member and an employee. What about when a person no longer wants to be an employee and instead wants to just be a person again?

Employee and Member are not true "is a" concepts. I may "be" an employee or a member, but that is not really what I truly am or the basis for my identity as an entity. Member and Employee are just two of a large number of roles that we also occupy in the course of being a Person.

Don't model a Role with inheritance, it does not work well. Instead just have Person and add a Roles collection that can change, support multiple participations by one person etc.

The rest ehhh. Map attributes where they logically belong, not based on some kind of policy or previous course of action. Services return whatever you want them to return, the underlying data structure should be logical and prevent duplication.

Upvotes: 1

Jagmag
Jagmag

Reputation: 10366

I would be tempted to go with 

Person ---is-a---> Member ---is-a--> Employee

That is presuming that there is something distinctly different in how "Employee" works as compared to "Member". There is nothing in your question to indicate that but i presume there will be some additional functionality in Employee that Member does not have.

Regarding your point about complexity, i would say that at this stage of your design, thats probably something that you are worrying about prematurely. 2 levels of object hierarchy is not just not all that complex - most decently sized systems usually have more than 2 levels if you try and separate the logic. Your point about complexity is something that you should think about more as your system grows and if it reaches levels where it becomes a lot more complex that this.

Upvotes: 0

Related Questions