Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GH-33 First version of port of AbstractEntity from DDDBITS #37

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

hschwentner
Copy link
Member

A base class for entities with convenience implementations for equals(), hashCode(), toString() based on the entities identity.

Belongs to issue #33

Questions:

  • is AbstractEntity the right name? Or would it be merged with interface Entity?

@hschwentner hschwentner added type: enhancement New feature or request module: ddd Domain-Driven Design related support labels Dec 7, 2020
@hschwentner hschwentner changed the title First version of port of AbstractEntity from DDDBITS GH-33 First version of port of AbstractEntity from DDDBITS Dec 7, 2020
@odrotbohm
Copy link
Member

odrotbohm commented Dec 7, 2020

I'm not sure I like adding implementation classes to jMolecules, even if abstract ones. All these base class are likely to encode some assumptions that are highly likely to be invalidated by a concrete project's requirements. Just the decision whether you'd want to allow an entity to live with a null identifier for a bit of time is taken away here.

Lifting those support classes up jMolecules rubber stamps them as the way to implement those interfaces when I'd argue there is no such one way. Is there anything wrong to keep those implementation helper libraries around and just move them to use jMolecules interfaces and annotations as needed?

Kind of what I already mentioned here.

@hschwentner
Copy link
Member Author

I'm not sure myself, if jMolecules is the right place for that. Just wanted to open the discussion again. I agree, there's not the way to implement it right and we don't want to pollute jMolecules with specific implementations. On the other hand every project that does DDD tactical design has to deal with implementing the identity. So every project that uses jMolecules has to deal with that.

Hm, maybe we should talk in person again :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
module: ddd Domain-Driven Design related support type: enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants