Creation of Paramore.Brighter.Abstractions

[preardon]

I would like an Abstractions Package that can contain our More External Contracts (i.e. IRequest, Event, Command ect.) and only re publish this once per Major

At the minute every time I Updated my Shared Packages, my colleagues need to update their version of brighter to consume these.

[preardon]

@iancooper @holytshirt what are your thoughts on this, I think if we're going to do this it will have to be either a v9 feature, or wait until v19. Happy to discuss on Wednesday

[iancooper]

Maybe. I'm always cautious about breaking up the core packages, Brighter and ServiceActivator outside of the need for external dependencies. I might need to understand the reason why this update cascade happens

[iancooper]

PS Not saying don't, just saying I'd like to understand the reasoning as this problem is not one I am encountering.

[preardon]

Effectively, because our packages require the same or newer versions of each other, the issue is when I upgrade to v9.0.1.preview5 my Domain.Events package (which just contains my internal shared events which are published to internal nuget) then requires this and when another team wants one of my updated events they then are forced to upgrade to the latest version of brighter so that they can consume my packages. If with each minor we only changed some of our more common and non changing interfaces (IRequest, Event, Command, ect.) This would mean that it only affects them if we upgrade to a newer version of the Abstractions package. It's not that they don't want to upgrade it's that they don't want to upgrade now, they just want the new versions of our packages.

I understand that there is a School of thought that says, don't share your events just the documentation, but not everyone wants to do this.

I suppose this might be less of a problem when we are out of Preview and upgrading minors should be a NoOp.

Anyway @iancooper let me know what you think?

[iancooper]

I am definitely in the ‘share schema not type’ school of thought - it’s one of the four tenets. I’m a little resistant to breaking up the core package with an abstraction package. Let me ponder, software is about trying to build a common model, so I need to ponder this need more.

…

On 28 Nov 2021, at 23:53, Paul Reardon ***@***.***> wrote:  Effectively, because our packages require the same or newer versions of each other, the issue is when I upgrade to v9.0.1.preview5 my Domain.Events package (which just contains my internal shared events which are published to internal nuget) then requires this and when another team wants one of my updated events they then are forced to upgrade to the latest version of brighter so that they can consume my packages. If with each minor we only changed some of our more common and non changing interfaces (IRequest, Event, Command, ect.) This would mean that it only affects them if we upgrade to a newer version of the Abstractions package. It's not that they don't want to upgrade it's that they don't want to upgrade now, they just want the new versions of our packages. I understand that there is a School of thought that says, don't share your events just the documentation, but not everyone wants to do this. I suppose this might be less of a problem when we are out of Preview and upgrading minors should be a NoOp. Anyway @iancooper let me know what you think? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[Herve-M]

Any news about this? Brigher / Darker try to promote "clean architecture (ports & adapters)" but still force to leaks implementation into domain and application layer/tiers making it impossible to just have DI setup at outer layer and abstraction only in the inner one.

[iancooper]

Can you give an example of how this concern manifests for me? I'm struggling to understand what folks looking for this are after. I think an example of where there is a problem would help.

[iancooper]

In a ports and adapters model, for example, a request handler is in the app, not the adapter.

[preardon]

I don't have strong feelings either way, a point I find interesting is that sharing the nuget for this is by and large useless without also sharing the Schema. I do however like the idea that if you were planning to obsolete it's a way of communicating it, and you could argue that it ensures that there are no Typos or issues with the schema, however I know these are not strong arguments.

This request came from one of our developers who was effectively "forced" to upgrade to Preview 3 to get our latest Types. Honestly I feel this will be much less of an issue after GA because there should only be braking / Arduous upgrades for each major.

[iancooper]

Going to move to a discussion over an issue