If you liked this article, listen to Dialexa’s VP of Software Engineering, Andrew Turner, on Custom Made talk technology reliability and security and how in today’s current landscape CIOs won’t get promoted if everything works. But they will get fired if anything doesn’t:Listen to all episodes of Custom Made for insights and perspectives from industry disruptors and technology leaders.
To help narrow down the answer to this question, we'll need to ask a few more: How well do you know your domain? Do you have domain experts on your team? Are you jumping into a new industry or area?
If you're lucky enough to have domain experts on your team with a vast knowledge of the industry or area your platform is targeting, there's a great chance you can leverage Domain Driven Design. Domain Driven Design (DDD), a term coined by Eric Evans, "provides a structure of practices and terminology for making design decisions that focus and accelerate software platform strategy projects dealing with complicated domains".
Domain Driven Design Best Practices
However, understanding domain driven design best practices is simply not enough for your team to be successful. You need to execute them. Eric Evans himself points out in a talk at the GOTO Conference, how time has shown even the best of teams struggle with discipline using Domain Driven Design on a monolithic scale. In his talk, he highlights how microservices helps drive these best practices by forcing teams to deal with domain boundaries.
All of that being said, if you feel so far microservices are the right fit for you, keep in mind a microservice approach might still not be your best option to start with. As Martin Fowler explains, "even experienced architects working in familiar domains have great difficulty getting boundaries right at the beginning." Simply put, getting domain boundaries right is hard and as we saw with the application continuum, solutions rarely are static. Even if you do define the domain boundaries right at the beginning, they may very well change over time. A monolithic approach at the start enables you to pivot faster to changing business requirements. Once you've solidified your architecture you can always break it apart into microservices. As Simon Brown has stated at various talks: "If you can't build a monolith, what makes you think microservices are the answer?"
Understanding Domain Boundaries
Still not sure where to start when choosing between a microservices vs monolithic approach? At Dialexa we go through various activities with clients to help understand their domain boundaries and how well we can define them. If it's difficult to define the boundaries, we generally lean towards recommending a monolithic approach at the start to allow for flexibility later on. If we have a high amount of confidence and detail in our domain boundaries we typically suggest a solution geared more towards microservices on the application continuum.
One simple activity we use only requires pencil and paper. Ask various team members to define the domain boundaries for your platform by themselves. After they're done compare the results. How similar are they? Are there significant differences? Are some areas harder to define? While this activity seems obvious and simple, it highlights your team's current understanding of the problems your platform solves. Armed with this knowledge you can make a better decision on where your team should start. But before you dive into coding your platform we'll take a look at the infrastructure choices you can choose from to power your solution in our next post!
If you want to learn more about our own processes, check out our free ebook, Platform Thinking: Creating Real-World, Scalable Platforms.