Fork me on GitHub
#architecture
<
2020-02-21
>
jlmr08:02:10

Hi, I was directed here from #off-topic. Can anyone recommend articles/books dealing with design decisions on how to divide a software system into different applications/services? I’m facing such a decision for the first time at work and am looking for tips and ideas on which factors I can/should take into account. Would be great to read about some methods and examples.

paul.dhubert09:02:33

I'm thinking of http://aosabook.org/en/index.html which goes into the details of such design decisions

pithyless09:02:02

https://dataintensive.net/ is great at discussing trade-offs of these kind of decisions

rickmoynihan12:02:30

My main advice would be if possible do it by the business/application domain/feature; i.e. do it vertically. And if possible avoid doing it horizontally, i.e. services by layer. Main reason is that it makes integration and development much easier; and all work on a feature will typically go together; and not touch multiple services/backends. Obviously this all depends on scaling needs etc and there may be good reasons to go horizontally; but all things being equal I’d default to trying to split vertically first.

pwojnowski09:02:54

I would start with Bounded Contexts from DDD.

jlmr09:02:09

Thanks for all the tips! Will look at them this weekend. There are also decisions to be made about deployment (to Docker or not to Docker) and platforms (plain VM’s or things like Elastic Beanstalk or Kubernetes), tips about making those kinds of decisions are also welcome!