In our last post of this series we discussed the application continuum and how it guides your software platform strategy. Understanding how your solution evolves over time opens your mind to various starting points, but we still haven't answered the question, "Where do I start?"

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 projects dealing with complicated domains".  

Our End to End Guide to Product Development

Domain Driven Design Best Practices

However, understanding best practices for domain driven design 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 understand where to start to leverage your platform strategy to drive digital transformation, download our free guide today, Enterprise Technology for Business Outcomes.  

Our End to End Guide to Product Development

Click to Comment