Is it possible to remove Entity from this library or move it into a sub namespace?
johannbrink opened this issue · 6 comments
Hi Vladimir
I really like your library and have also watched all your PluralSight courses over the last 18 months.
I have used your examples as the foundation of many applications.
I do have my own base classes for Entity and ValueObject in my Project.Domain layer that is based on Onion architecture. I do not import any nuget packages in the Project.Domain layer.
In my Project.Application layer I am less opposed to importing nuget packages. I did fork your result classes and have them in my application layer. I would much rather import your nuget package in the application as that is also the place where I import things like Mediatr. It would be a bit confusing for other developers if there are 2 entity and value object classes avaiable.
If you can't remove Entity or ValueObject, perhaps you can consider moving into CSharpFunctionalExtensions.Entity and CSharpFunctionalExtensions.ValueObject so that they are not visible when a person imports CSharpFunctionalExtensions?
Thanks for your great work and course content!
Unfortunately, removing ValueObject from the library would break a lot of clients because it's been there from the very beginning.
Importing nuget packages in the domain layer isn't bad per se. It's only when those nuget packages refer to out-of-process dependencies (or aren't related to the problem domain) do they become a problem. Think of primitive types such as int and string. They are essentially from a nuget package too. More on this topic: https://khorikov.org/posts/2021-07-05-domain-model-purity-boundary/
What are the differences with your implementation that you can't use the library's version?
Thanks for getting back to me.
It may reduce the severity of the breaking change if you just move it to a related nuget package instead, something like CSharpFunctionalExtensions.DomainModelling or similar that those people can just import in addition to the base package.
My entity class looks the same as yours, I've just added domain events and a raisedomainevent function to it because I'm allowing pre and post persitence domain events to be raised from both aggregates and entities.
PS, for now I've decided to import this package even into our .Domain project so it's not a big deal. Would be nice to have the flexibility in the future.
I will need to think about this. Maybe it would indeed make sense to split the library into several nuget packages with CSharpFunctionalExtensions.Result, CSharpFunctionalExtensions.Maybe, and CSharpFunctionalExtensions.DomainModeling, but keep the CSharpFunctionalExtensions for those who still wants all the functionality in one package.
In your case, you can make your own Entity (or AggregateRoot) class that inherits from the library's Entity and introduce the events functionality this way.
Vladimir, just a suggestion about CSharpFunctionalExtensions.DomainModeling. Domain layer maybe not be implemented with functional programming style. Something like Vhorikov.DomainModeling sounds like a more applicable name.
Does it bring a breaking change if you extract classes to separate packages and make CSharpFunctionalExtensions just a reference package with TypeForwardedToAttribute specified?
Domain layer maybe not be implemented with functional programming style. Something like Vhorikov.DomainModeling sounds like a more applicable name.
It would be a more appropriate name if this is was a new library, but since these types have been in CSharpFunctionalExtensions for years, it'd make more sense to keep CSharpFunctionalExtensions (as in CSharpFunctionalExtensions.DomainModeling) for historical reasons.
Does it bring a breaking change if you extract classes to separate packages and make CSharpFunctionalExtensions just a reference package with TypeForwardedToAttribute specified?
That's something I need to investigate, not sure about that.