3 ms·

This is more likely to be a problem if you split your services up by noun (Users,Orders) rather than by function (makeOrder, loginService, etc). This isn't bull

by jzoch 8y ago

This is more likely to be a problem if you split your services up by noun (Users,Orders) rather than by function (makeOrder, loginService, etc). This isn't bulletproof either but I've seen it helps reduce this occurrence a lot. Pardon the poor examples

ChicagoDave 8y ago
In other words, data store (domain), behavior (createOrder), and event (orderCreated). I feel the OPs pain but I’ve built MSAs from DDD principals and it really is a better architecture for complex systems.
karmakaze 8y ago
This is the most important point when making microservices. There's lots of talk about bounded contexts but very little about how to draw the boundaries. Most are superficial and repeat bad examples like OrderService (order is both a verb and boun, OrderingService sounds ok). Using two part service names (ContentComposition, MessageDelivery) usually works out well. As to the shared db aspect, while spitting a miniservice into micro ones I had this situation. All the code was split first and the db changes being the most difficult to was done last as a point.of we don't expect to revert this.choice. We weren't at a performance limit so that was fine, any schema changes had to be clearly communicated and coordinated. In all not too bad. I don't think I'd want to leave it in that state as a normal state. The point of micro is Independence and isolation of changes and sharing a db leaves a sensitive area. Don't let that stop you if it's only a temporary state. Just get commitment as to how temporary that is, since in absolute terms everything's temporary.
- sigi45 8y ago
  Why would you make Miniservices?
  - karmakaze 8y ago
    We never had the intention to make miniservices. Some were microservices that acquired abilities that grew to become separate microservices. On other projects they were prototypes that lasted long enough and became small monoliths to get split up.

by jzoch 8y ago

ChicagoDave 8y ago

In other words, data store (domain), behavior (createOrder), and event (orderCreated). I feel the OPs pain but I’ve built MSAs from DDD principals and it really is a better architecture for complex systems.

karmakaze 8y ago

This is the most important point when making microservices. There's lots of talk about bounded contexts but very little about how to draw the boundaries. Most are superficial and repeat bad examples like OrderService (order is both a verb and boun, OrderingService sounds ok). Using two part service names (ContentComposition, MessageDelivery) usually works out well. As to the shared db aspect, while spitting a miniservice into micro ones I had this situation. All the code was split first and the db changes being the most difficult to was done last as a point.of we don't expect to revert this.choice. We weren't at a performance limit so that was fine, any schema changes had to be clearly communicated and coordinated. In all not too bad. I don't think I'd want to leave it in that state as a normal state. The point of micro is Independence and isolation of changes and sharing a db leaves a sensitive area. Don't let that stop you if it's only a temporary state. Just get commitment as to how temporary that is, since in absolute terms everything's temporary.

sigi45 8y ago
Why would you make Miniservices?
- karmakaze 8y ago
  We never had the intention to make miniservices. Some were microservices that acquired abilities that grew to become separate microservices. On other projects they were prototypes that lasted long enough and became small monoliths to get split up.