4 ms·

I'm a big fan of the modular monolith pattern. I usually make domain modules as independent as possible and invert dependencies for web and persistence layers.

I'm a big fan of the modular monolith pattern. I usually make domain modules as independent as possible and invert dependencies for web and persistence layers. If you design well you can break off domain-based services whenever the advantages warrant it.

gen220 6y ago
If you ever have to start a big company from scratch, this is how to do it. There aren’t any major drawbacks to this model when a business is young (first couple years). The downsides appear when you have different parts of your application with very different load requirements. It also takes a lot of discipline to write code this way. Without strict code review and more experienced hands, the bounded contexts fall apart. One of the advantages of the microservices model is it limits the damage people can do. :) It forces a bounded context on a team of engineers and says “hey, play in this sandbox and follow these SLAs. If your internal designs are awful, good luck.”
- fiddlerwoaroof 6y ago
  It mostly hides the damage: instead of a code base no one understands, you have network traffic no one understands.
  - ct520 6y ago
    I’ll take the latter any day with good patterns of aggregating to a grey log. Having to triage production issues in a multiple application saas environment, The latter has always been easier to me. Don’t get me started on trouble shooting someone else’s crazy event queues
    - fiddlerwoaroof 6y ago
      This is really interesting to me: I’ve always found dealing with code preferable to dealing with network communication. It might be because the languages I work with (common lisp, Clojure and Scala/Java/Kotlin) all have excellent code navigation abilities.
      - gen220 6y ago
        If you have a monorepo, you get both! (You can grep for logging messages in the services you’re calling).
        fiddlerwoaroof 6y ago
        What would be even better is some way to use swagger/graphql to jump from frontend api calls to backend code
      - ct520 6y ago
        That would make sense in a perfect world to me. I would prefer it too. This company I worked for was leader in its industry and many vertices. It had legacy apps from 80s still running through today. Probably 30 SAAS based applications or so. Many many different languages used. Many using internal services and queues to communicate with each other. With 100's if not 1000's of B2B integrations, pumping millions of requests through their portal at any given time. (they also maintained their own data centers.) Anyways, given my experience and troubleshooting message queuing etc and jumping in new code bases all the time. I was more like a blend of SRE / Dev / IT / Product manager. (yeah I know). Given I worked across the SDLC I always found it easiest to, establish the problem statement and the behavior around it. The expected behavior, then dive into the gray log with a unique piece of information that should be logged and trace it from there. To each their own. Unfortunetly with architecture this way I commonly see "segmentation" between Support/Ops/Dev were a problem can end up in limbo. That's were I would hop in.

gen220 6y ago

If you ever have to start a big company from scratch, this is how to do it. There aren’t any major drawbacks to this model when a business is young (first couple years). The downsides appear when you have different parts of your application with very different load requirements. It also takes a lot of discipline to write code this way. Without strict code review and more experienced hands, the bounded contexts fall apart. One of the advantages of the microservices model is it limits the damage people can do. :) It forces a bounded context on a team of engineers and says “hey, play in this sandbox and follow these SLAs. If your internal designs are awful, good luck.”

fiddlerwoaroof 6y ago
It mostly hides the damage: instead of a code base no one understands, you have network traffic no one understands.
- ct520 6y ago
  I’ll take the latter any day with good patterns of aggregating to a grey log. Having to triage production issues in a multiple application saas environment, The latter has always been easier to me. Don’t get me started on trouble shooting someone else’s crazy event queues
  - fiddlerwoaroof 6y ago
    This is really interesting to me: I’ve always found dealing with code preferable to dealing with network communication. It might be because the languages I work with (common lisp, Clojure and Scala/Java/Kotlin) all have excellent code navigation abilities.
    - gen220 6y ago
      If you have a monorepo, you get both! (You can grep for logging messages in the services you’re calling).
      - fiddlerwoaroof 6y ago
        What would be even better is some way to use swagger/graphql to jump from frontend api calls to backend code
    - ct520 6y ago
      That would make sense in a perfect world to me. I would prefer it too. This company I worked for was leader in its industry and many vertices. It had legacy apps from 80s still running through today. Probably 30 SAAS based applications or so. Many many different languages used. Many using internal services and queues to communicate with each other. With 100's if not 1000's of B2B integrations, pumping millions of requests through their portal at any given time. (they also maintained their own data centers.) Anyways, given my experience and troubleshooting message queuing etc and jumping in new code bases all the time. I was more like a blend of SRE / Dev / IT / Product manager. (yeah I know). Given I worked across the SDLC I always found it easiest to, establish the problem statement and the behavior around it. The expected behavior, then dive into the gray log with a unique piece of information that should be logged and trace it from there. To each their own. Unfortunetly with architecture this way I commonly see "segmentation" between Support/Ops/Dev were a problem can end up in limbo. That's were I would hop in.