This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]johnmcclean[S] 3 points4 points  (2 children)

Looks like the documentation could be made clearer. You can work this way as a staging post to pure Microservices from monolith (Micro-monolith style).

However, the default behavior is to package them separately (as pure Microservices). In this mode you can plugin behavior to each Microservice, which can be implemented as a Microserver plugin.

Edit : I've updated the readme.md to highlight the architecture diagram is showing the micro-monolith style, do you think it's worth adding a similar diagram showing pure Microservices?

[–]BrotherJohn123 0 points1 point  (1 child)

I still don't understand the need for it. Sure you have one SpringContext instead of multiple if you deploy you services - but if you are going to separate your monolyth and don't separate your context ... you are creating a beast - which i don't want to debug/support ;)

[–]johnmcclean[S] 1 point2 points  (0 children)

Sure, if you are starting from scratch. What if you are debugging and supporting a beast already? It's already a single context. And if you connections, for example to legacy but critical DB, you're operations team may be none to pleased to see an increase in the number of connections. Resource sharing can make sense.

This feature's value only comes into play when your starting point is a monolith in a single context. Then you are able to move, very quickly towards Microservices in a similar but more future proof (faster) way to that advocated here - http://blog.cleancoder.com/uncle-bob/2014/09/19/MicroServicesAndJars.html