Reputation: 1631
I am new to the DDD architecture pattern. I am designing the behaviors on my domain based on the Use Cases that were captured. I am not putting the logic in the behavior just creating the signatures.
My question is what is best approach when 2 Domain model share or have the same behavior?
example: I have a TimeEntry Domain and a TimeApprover Domain, they both have the same behavior AddCommentToTime(). They both have the same behavior and eventually persist to the same logical table.
In other Architectures AddCommentToTime() would of been pushed to some type of base or abstract class so that both TimeEntry and TimeApprover could share the same code.
But in pure DDD there should be NO sharing, and those domains should have separate behaviors and NOT inherited/implemented from any type of base or abstract class? They should basically be independent of each other.
Am i understanding this correctly?
EDIT from answer
@Matthew's answer helped me re-look at the what I as actually trying to accomplish.
The behavior AddCommentToTime() actually belong in an entirely different Domain. after re-looking and at the use cases and data design we are implementing I realized that AddCommentToTime() should actually be AddcommentToAssignment(). Add there is going to be an Assignment Domain. This Assignment Domain will know how to Add a comment.
Upvotes: 1
Views: 276
Reputation: 25793
The first thing to note is that DDD is not an architectural pattern, though you can use architectures that conform to the DDD methodology.
As for two classes in different domains (bounded contexts?), if it's a trivial code I would just duplicate it, otherwise you could put it into the shared kernel and have both inherit from it. Alternatively you could use the strategy pattern to do it at run-time instead of compile-time, and put the strategy implementation into the kernel again.
Upvotes: 1