What do you think about moving your third party integrations into gems. In my time in the Java/Kotlin world, in support of microservice eco systems, we would externalize all of our clients. This also ment that contracts between domains we owned were also externalized shared clients.
I think moving domains to lib is the first step in this process👍. It helps to provide a distinction between concerns. It does may it harder to keep them from having unnecessary coupling but that can be trained. Once you move to the time when multiple concerns are too much for a single app its much easier to move those into encapsulated services.
When you package an interaction and create an artifact you are also encapsulating the dependencies security constraints. It can be scanned, approved, and deposited in an self-owned artifact vault so its trust can be assured even if not shared.
The problem to that approach is that there is a lot of business logic that depends on other business logic that the gem couldn't possibly know about.
e.g. the Blockfires gem would have to know that each transaction is used by models A, B, C
If we move models A, B, C to the gem, then the gem's gotta know about the database setup, right?
All of our internal, private gems have thin wrappers in the monolith for this reason. There are interactions in the monolith that each gem doesn't know about.
Third-party integrations as gems may work better in a microservices architecture, though!
I agree but only if the domain delineation is based on business logic. Your integration with blockfire should be concerned with communication.
Consider if you had an event driven system and each model and associated business logic was a domain distributed to its own service cluster. The service knows what model it maintains, some other system will have to probably manage the eventual consistency state of such operations but there are some interactions that all these services share related to blockfire and those should be delegated to a client. The hope is next time a new model crops up, we can stand-up a new domain that inherits how your org uses blockfire.
The distinction is, treating your toolchains like internal platforms. You don't wanna share models but you wanna make expansion of business behavior easier to onboard.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
What do you think about moving your third party integrations into gems. In my time in the Java/Kotlin world, in support of microservice eco systems, we would externalize all of our clients. This also ment that contracts between domains we owned were also externalized shared clients.
I think moving domains to lib is the first step in this process👍. It helps to provide a distinction between concerns. It does may it harder to keep them from having unnecessary coupling but that can be trained. Once you move to the time when multiple concerns are too much for a single app its much easier to move those into encapsulated services.
When you package an interaction and create an artifact you are also encapsulating the dependencies security constraints. It can be scanned, approved, and deposited in an self-owned artifact vault so its trust can be assured even if not shared.
The problem to that approach is that there is a lot of business logic that depends on other business logic that the gem couldn't possibly know about.
e.g. the Blockfires gem would have to know that each transaction is used by models A, B, C
If we move models A, B, C to the gem, then the gem's gotta know about the database setup, right?
All of our internal, private gems have thin wrappers in the monolith for this reason. There are interactions in the monolith that each gem doesn't know about.
Third-party integrations as gems may work better in a microservices architecture, though!
I agree but only if the domain delineation is based on business logic. Your integration with blockfire should be concerned with communication.
Consider if you had an event driven system and each model and associated business logic was a domain distributed to its own service cluster. The service knows what model it maintains, some other system will have to probably manage the eventual consistency state of such operations but there are some interactions that all these services share related to blockfire and those should be delegated to a client. The hope is next time a new model crops up, we can stand-up a new domain that inherits how your org uses blockfire.
The distinction is, treating your toolchains like internal platforms. You don't wanna share models but you wanna make expansion of business behavior easier to onboard.