Repository navigation
Should we have base types to avoid boilerplate code? #33
Description
Activity
There are already building block types in jMolecules that follow the type constraints outlined in John Sullivan's Advancing Enterprise DDD blog post. I just checked our interfaces and it looks like they deserve a round of polish. PR coming.
Regarding
TinyType: I'm not sure it's worth a superclass to basically defaultequals(…)/hashCode(). That said I am not decidedly opposed to introduce it. It leaves us with a few open questions though:- So far user domain types are supposed to either use annotations or the base types. I.e. it feels odd having to extend the class and also annotate it with
@ValueObject. Following the patterns for the other types, shouldn'tTinyTypebecomeValueObjectin the first place? - All other building blocks types are interfaces.
TTbeing a class would break that to some degree and we'd have to argue why you can implement one and have to extend the other. - Value objects cannot only be types wrapping a single value. I.e.
TTcurrently seems to cater the common but still a bit special case of a single value in that type definingequals(…)/hashCode().
Summarizing, the existence of
TTseems to be entirely catering technical convenience. Does it maybe make sense to introduceValueObject<T>exposingT value()and leaveTinyTypeas an implementation of that living in a different project or potentially even in user land completely?- So far user domain types are supposed to either use annotations or the base types. I.e. it feels odd having to extend the class and also annotate it with
- added a commit that references this issue
on Oct 27, 2020 - added a commit that references this issue
on Dec 7, 2020 Where did y'all land on the
ValueObjectdiscussion? I notice that it has not yet landed in the building block types. I'm starting to pull jMolecules into my teaching codebase, andValueObjectis noticeably absent.I am still not sure we want to get in the business of defining domain implementation classes as it's way too easy for them to become unusable in a certain technical context which is at odds with the importance their sole existence implies, should we ship them.
For now, I'd vote those implementations to live in a dedicated, separate library, so that's an opt-in and also is slightly less prominent than the interfaces and annotations we ship as core jMolecules. For all already existing technology integration, we just recently decided to move code of similar kind into a separate repository so that it can be released independently and is also perceived as something "transitive".
Does that make sense?
Reacted by Marc von Renteln
The DDDBITS provide two kinds of things:
From the DDDBITS documentation:
Entities
From the Blue Book we know that entities must have an identity.
Typically we want that
equals()andhashcode()are based on this identity.The base class
Entity<ID>provides implementations for this.Example:
Value Objects
Since we don't have value types in Java yet, we have to simulate values with objects.
(That may change with the advent of Project Valhalla.)
For the time being, this means unfortunately that we have to write a lot of boilerplate code for a well-implemented value object.
DDDBITS provide so called tiny types that help to reduce that boilerplate code for simple value types.
Example:
Value Objects are identityless and immutable.
Immutability in Java comes with only final fields plus methods that never mutate the state.
(That means we only have commands in the sense of command-query-separation[3].)
No identity in Java is reached by overwriting
equals()with an implementation that is based on the values of the fields.Such an implementation and similar implementations for
hashcode()andtoString()are provide by theTinyType<V>super class.Something similar could be done with Lombok, but many projects do not want to couple their domain layer to a technical library.