Add kMolecules DDD flavor of jMolecules DDD to work around issues in Kotlin

[jntakpe]

jMolecules DDD types are helping a lot but there are some annoying limitations due to Kotlin's Java interoperability.

The main limitation is due to Identifiable#getId method that conflicts with constructor's id field as shown below:

//Won't work as Kotlin's generated getter has the same signature as Identifiable#getId method
class Conflict(val id: Id, val other: String): Entity<Portal, Id> {
    override fun getId(): Id = id
}

// Won't work as id 'overrides nothing'
class Override(override val id: Id, val other: String): Entity<Aggregate, Id>

Obviously it is possible to rename constructor's id field but it makes framework integration brittle since projects such as the excellent Spring Data instantiates objects via constructor if I'm not mistaken. It also hurts Kotlin's conciseness and integrate poorly with Kotlin's data classes.

To cope with those issues I created Kotlin counterparts for jMolecules DDD types. I would be happy to contribute a PR if you think it makes sense

[odrotbohm]

You seem to run into this ticket which – unfortunately – hasn't seen any significant progress since it was filed 6 years ago. I can certainly take the suggestion forward to the team but my gut reaction is that I (we) don't want to introduce and maintain an additional artifact replicating another artifact, just to fix a problem in the target language.

The linked ticket has a suggestion of how to make this work using inline and actually declared methods. I know this is not as elegant as it could be, but I don't see why the proclaimed elegance of a language should create significant overhead library authors of a language they allegedly integrate seamlessly with.

[jntakpe]

Ok ! It makes sense. I will most likely create a fork to ease Kotlin integration for Kotlin users

[odrotbohm]

I gave this a bit more thought and briefly thought it might be okay to just coin a new kMolecules project and repo and ship something similar to what you proposed in your PR, assuming someone was willing to contribute and maintain any of this.

But what the occurred to me is that virtually everything in jmolecules-integrations would need to be either copied over or needed to be made aware of the Kotlin re-declarations of the artifacts. That currently seems like a bad tradeoff between gain and cost, given that nobody of the team has significant expert experience with Kotlin to avoid running into language-specific gotchas or the time to basically replicate and keep the port of all the integrations up to date.

[odrotbohm]

Word is on the street that we might see movement on the related ticket in Kotlin soon. In that light, I'd refrain from moving forward with anything Kotlin specific, as I expect it to be just working with the Java-based abstractions as is.

[jntakpe]

Waiting for a decision I've created a library that mimics jmolecules-ddd with types easier to use in Kotlin here

[odrotbohm]

That's wonderful, thanks! I can take this to our team meeting this afternoon. Would you be generally interested in moving this repo to the xMolecules org?

[jntakpe]

Yes sure !

[odrotbohm]

There have been a few thoughts and questions coming up in the team call, that I would like to forward:

• We would like to move to a org.jmolecules:kmolecules-ddd artifact identifier to make the switch as simple as changing the j into a k for the artifact identifier.
• Question remains whether this should be a separate repository or could just be a separate module in the current jmolecules repository. The latter would make it easier to release and avoid the JAR being "something separate" but would ultimately require the build to switch to Maven. Is that something you would be okay with?
• We were wondering whether we could use the identical package name (org.jmolecules.ddd) as that would allow existing integrations to pick up the Kotlin-based annotations and interfaces without additional need for integration. That of course assumes that only one of the two would ever be on a project's classpath, and the methods exposed by the interfaces semantically equivalent to the Java counterparts. Do you think that would cause any problems?

[jntakpe]

Ok

• Regarding your first point sure no problem.
• No problem to switch to Maven. The GH-51 Better Kotlin integration #52 is already built with Maven
• Regarding the last to be able to provide a correct answer I should run some test with the different integrations. But sure if it works it is way better to do it that way.

However I won't be able to work on it for the next two weeks

[odrotbohm]

I gave this a quick spin, and it seems to work as expected. I would go ahead and commit the types you created into the tweaked module setup, with you as the official committer and take it from there?

[odrotbohm]

That's in place now!

[odrotbohm]

I've added a rudimentary Kotlin example project that shows the existing integration working.

[jntakpe]

Great thanks. All good for me