[joshdick]

Sharing a framework for logging, routing, and other boring things is fine; sharing a framework with domain-specific logic is when you start getting into trouble. Now if you want to change something in that framework, you have to change and deploy every last one of your services.

[lugg]

> sharing domain specific logic

Isn't that just called a business requirement?

> you have to change and deploy every last one of your services.

How is that different to code duplication as the article recommends? When business requirements change all affected code points needs to change.. you can't just wish that away.

-

The real problem here is mismanaging seperation of concerns.

Cqs mostly solves the hard problems. But having shared read objects will, at times, require multiple systems to make use of the same domain logic. Whether you're better off with code duplication or a hard shared dep is a trade off up to you to figure out. I tend to go with a mix that makes sense based on expected frequency of change and how breaking the changes are likely to be.

Another microservices is also one answer but can be an unworkable bottleneck for a lot of these types of situations.

[root_axis]

> Now if you want to change something in that framework, you have to change and deploy every last one of your services.

Do you? As long an appropriate versioning strategy is in place, it seems to me that you would only need to update the service that prompted the code change, leaving the other services to use the older version. If the other services need to have their code changed as well, then that'd be the case whether or not you used a shared library, except you'd have to update the code in 12 places instead of just one.

[3pt14159]

I don't know that many frameworks with domain-specific logic. It almost seems like a contradiction in terms.

[NathanKP]

A classic example that I've encountered would be using some custom web socket RPC protocol for communication between microservices instead of just using plain HTTP.

It can be tempting because an engineer thinks "I can optimize this and reduce the network overhead using this creative protocol." But now they have put themselves in a situation where if anything in that custom protocol changes they will have to update every single microservice in their backend ecosystem.

[rco8786]

How is that not a problem in HTTP?

This is just API versioning, that needs to happen regardless of the protocol you choose.

edit I see you mean the protocol itself (like if gRPC goes from version 1 to 1.2 or something). Yes, that's a thing... most protocol developers are careful about backwards compatibility to allow for some services to be behind a few minors to account for this. Also, HTTP still isn't invulnerable to this...HTTP/2 is very much a thing.

[Falling3]

That's really not domain specific though. It's just a proprietary protocol.

[dec0dedab0de]

Now if you want to change something in that framework, you have to change and deploy every last one of your services.

would the alternative be changing every one of your services, then deploying?