As you build new projects for various teams, you realize that every time, you have to start from scratch, because there is no single solution or pattern that works in all cases. It's tricky because you can very easily bring in successes from your past and try to fit them into your current project. The most fundamental principle that an architect must understand is the context and use cases in which each pattern works. You cannot build microservices when you have a 10-person team and you need to go to market in 4 months, because the overhead is just too much. That might work if you have the kind of engineering backing with a platform team and a very mature DevOps team who can help you be up and running easily.
One of the best books I've read recently is 'Fundamentals of Software Architecture' by Mark Richards and Neal Ford. It is a very clear book, where every 'It Depends' is backed by the metrics that have to be evaluated based on your context. Scalability might be an important driver for you if you are an internet-based B2C company, but not so much if it is an enterprise product. Every architect who has been through a handful of greenfield projects will have a base to start with though, which would work well within the domain or organization or scale that they are working with. In my upcoming posts, I'll share the combinations that have worked for me, along with detailed insights on each decision.
Among the various architectural styles discussed, I found the chapter on 'Service-Based Architecture' especially enlightening. Here's a snippet from Chapter 13:
"Service-based architecture is a hybrid of the microservices architecture style and is considered one of the most pragmatic architecture styles, mostly due to its architectural flexibility. Although services-based architecture is a distributed architecture, it doesn't have the same level of complexity and cost as other distributed architectures, such as microservices or event-driver architecture, making it a very popular choice for many business-related applications."
This style is described as 'domain-partitioned architecture,' reflecting how the structure of services is driven by the domain. This aligns with my preference for a domain-based view in the code base, as I discussed in a previous blog post (https://maybeitdepends.com/the-one-thing-that-will-change-the-way-you-code). I plan to delve deeper into how CQRS elevates this approach in my current projects.
While exploring names for the architectural style I employ, I found a striking resemblance with the description in the book. It involves one or a few monolithic databases, a separate UI, and a set of modular services that can be split into separate deployable units as needed. In the above book, there is a star-rating page for each architecture style. Service-based architecture is one where none of the architectural characteristics have a 1 star or a 5 star rating. "Elasticity" is the one aspect where it scores 2 star, and each of other 10 characteristics has either a 3 or 4 star. For comparison, EDA has four 5 stars, but it has 1 star in "Simplicity". Microservices has 1 star in both "Simplicity" and "Overall Cost".
There is no way I will be able to tell you this is the best combination. But if you have to work on a complex domain for a B2B customer or enterprise level without going internet scale, but have lots of flexibility, simpler designs and lower cost, this architecture should be something you should evaluate.
