MassTransit with a Microservices Architecture in asp.net core and docker

[Joseph de Ronde]

Hi All,

I am struggling with this a bit and was wondering if anyone was available to help out at all.

I have a project, we were using a simple in memory RabbitMQ simple service bus as can be found in the eShopOnContainers sample project here: https://github.com/dotnet-architecture/eShopOnContainers

Lets take the simple example i have been trying to get to work for example.

Basket.API and Catalog.API

Basket is the consumer of an event from the Catalog - Product Price Changed (when the price is changed, it should push a ProductPriceChangedEvent onto the bus and should be picked up by the consumer in Basket and update a redis cache)

I did have the Event ProductPriceChangedEvent in both the catalog and the basket, but have realised that as they are now in different namespaces MassTransit does not wire them up.

I have moved the Event into a separate class library now and referenced the event from there (works fine)

My problem with this approach is that Micro-services should own their own data, so the models should be in the micro-services themselves. A whole bunch of my events use these models to pass data to and from service via the bus (i.e. Accepting an order event has a Basket in it). I do not want to create a common domain project so that the events can reference that project (only way i can see around this at the moment) so if anyone knows a way around this i would be very great full.

Is there a way to make mass transit ignore the namespace and just accept a message of type name or is there some other way around this my melted brain has not picked up on yet?

Many thanks in advance, if you need any clarifications please ask away.

Joe.

[César Demicheli]

You can always setup the topology manually. Or just keep only the messages contracts shared between projects.

eShopOnContainers already have a lot of infrastructure and common codebase shared between several projects, so I don't see much trouble on having also the messages contracts shared between them.

Remember that, in the end, these contracts make up for your entire solution, not just an isolated project.

Hope this helps.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/7ed52e3d-c616-41a5-a64f-2605a6f8338b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Joseph de Ronde]

Hi Cesar

By message contracts do you mean the events and eventhandlers/consumers - I had started to migrate the events into their own shared library. However the problem I the have with that is that the models are then not in that class library(I.e. Basket or Order etc). So I would end up needed to separate the models out into a kind of domain layer. 

I may have completely mis interpreted what you have said, could you give an example? 

Many thanks

Joe.

To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/CAKUeuqJfTKTndDPq_vPs4Me42oUwBLi5J%3D3apCvJrpPvk2ZQkg%40mail.gmail.com.

[César Demicheli]

I meant just the messages for events/commands (remember we refer to them as contracts as MassTransit recommends using interfaces, not classes). Event handlers and consumers should remain on their own project as they are part of their service.

Messages contracts are not part of your domain model at all. They're just interfaces to communicate services between them.

It is logical that since messages contracts are a shared type between several projects, that they are placed in a shared class library. Without anything else, you are only coupling the dependent projects by that class library, nothing else.

I'm open to another perspective on this subject though ;)

To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/CAD94PS3_-O6_H9V-G3D4AiWDQ7ZQD-nk1htkbv5mxY9%2B0DwBPQ%40mail.gmail.com.

[Joseph de Ronde]

Hi Cesar,

Just wanted to thank you for your help the other week. We have separated out our events into an shared event library and separated out our domain objects into sperate libraries. Then referenced the required domain libraries in the events library. All of the event handlers are in the APIs thus keeping it all nicely structured.

Joe

To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/CAKUeuqJaScfOjAhFNcGH7ekxBG6Yyn7Y1c3%3DHx1UUJ3AXthVpA%40mail.gmail.com.

[César Demicheli]

You are welcome!! =)

I'm glad it was useful for you and that I could help :) :)

Cheers!!

To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/CAD94PS2_wc6ka8M7A585Zaw7gBzsZSYh8t-7nb-mG2w%3DHiPLWw%40mail.gmail.com.

[Jack Ni]

check this out, my repo. I used MT build entire service bus and micro-service at work

https://github.com/jackni/WorkFlowSagaStateMachineWithEFCore.

there is also a repo I did use redis

[Alexey Zimarev]

It is not a good practice to have a "shared" library that contains all events. Every service should provide its contracts for the outside world to communicate with it. Would those be commands, events, or API schemes, it doesn't matter. Contracts can be distributed as compiled libraries, using nuget packages or similar. But it is just fine to copy the contract code from one place to another as soon as the consumer of the contract clearly understands that the code is external to it and cannot be changed.

It is not really related to microservices or Docker. This is just a basic principle of a distributed system like we know it for more than 20 years.

[Eric Piraux]

I fully agree with that

Think boundaries first !

 

---

De : masstrans...@googlegroups.com de la part de Alexey Zimarev <azim...@gmail.com>
Envoyé : samedi, janvier 26, 2019 20:16
À : masstransit-discuss
Objet : Re: [masstransit-discuss] MassTransit with a Microservices Architecture in asp.net core and docker

 

It is not a good practice to have a "shared" library that contains all events. Every service should provide its contracts for the outside world to communicate with it. Would those be commands, events, or API schemes, it doesn't matter. Contracts can be distributed as compiled libraries, using nuget packages or similar. But it is just fine to copy the contract code from one place to another as soon as the consumer of the contract clearly understands that the code is external to it and cannot be changed.

It is not really related to microservices or Docker. This is just a basic principle of a distributed system like we know it for more than 20 years.

--

You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/b6bb77a6-597d-45f9-9578-4bc796eca27c%40googlegroups.com.

[hey!]

Hello! 

This link is broken. I could not locate the repo. DO i need permissions to access this repo? Please advise? 

https://github.com/jackni/WorkFlowSagaStateMachineWithEFCore

thanks,

Thiru

[Jerry Lee Daniel]

MT103/202 DIRECT WIRE TRANSFER
PAYPAL TRANSFER
CASHAPP TRANSFER
ZELLE TRANSFER
TRANSFER WISE
WESTERN UNION TRANSFER
BITCOIN FLASHING
BANK ACCOUNT LOADING/FLASHING
IBAN TO IBAN TRANSFER
MONEYGRAM TRANSFER
IPIP/DTC
SLBC PROVIDER
CREDIT CARD TOP UP
DUMPS/ PINS
SEPA TRANSFER
WIRE TRANSFER
BITCOIN TOP UP
GLOBALPAY INC US
SKRILL USA
UNIONPAY RECEIVER

Thanks.


NOTE; ONLY SERIOUS / RELIABLE RECEIVERS CAN CONTACT.

DM ME ON WHATSAPP
+44 7405 896213