architecture

jlmr 2020-02-21T08:59:10.036400Z

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.

pwojnowski 2020-02-21T09:01:54.037600Z

I would start with Bounded Contexts from DDD.

👍 1
robertfw 2020-02-21T09:01:59.037800Z

@jlmr This talk at the recent Conj may have some ideas for you https://www.youtube.com/watch?v=ct5aWqhHARs&list=PLZdCLR02grLqSy15ALLAZDU6LGpAJDrAQ

👍 1
pauldub 2020-02-21T09:02:33.038Z

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

pithyless 2020-02-21T09:10:02.038200Z

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

⬆️ 3
jlmr 2020-02-21T09:24:09.040100Z

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!

2020-02-21T12:47:30.041300Z

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.