> I think that the most important part of a system design is the logical decomposition initially, and secondarily the topology (servers and pods, networks, etc)

> I think that the most important part of a system design is the logical decomposition initially, and secondarily the topology (servers and pods, networks, etc). If the aspects of the logical design (domain?) are correct we should be able to arrange things in different topologies as we grow. That sounds reasonable, but defining a good decomposition initially is perhaps very hard! One concrete rule of thumb to define a decomposition is to apply Parnas' criteria: > We have tried to demonstrate by these examples that it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. [...] -- Parnas, 1972 But, for a new domain, it's still going to be challenging to be able to identify an a effective decomposition up front. Maybe once you've built 2 or 3 instances of a similar application in a similar problem domain, it starts to be easier to figure out what an effective decomposition is likely to be up front. Another approach is to embrace the fact that you're not going to be able to decompose the system correctly up front, and figure out how to structure development to accomodate that. I.e., how do you set things up to create the flexibility to change the decomposition mid way through delivery taking into account what you've learned. E.g. if you're tossing up between a mess in 1 git repo owned by one team vs carving up the problem and handing out the spoils chunk by chunk to teams scattered across a fixed org chart, prefer the thing that makes it easier to rapidly and flexibly adapt and cheaply change decomposition: e.g. everything in a big mess owned by 1 team in 1 repo where it's possible to adjust decompositions without handoffs or external dependencies. see also > one thing grug come to believe: not factor your application too early! > early on in project everything very abstract and like water: very little solid holds for grug's struggling brain to hang on to. take time to develop "shape" of system and learn what even doing. grug try not to factor in early part of project and then, at some point, good cut-points emerge from code base -- https://grugbrain.dev/ https://grugbrain.dev/