Domain-first
Domain-first thinking is heavily influenced by the principles discussed by Eric Evans in his book Domain-Driven Design: Tackling Complexity in the Heart of Software (Addison-Wesley Professional). For enterprise-scale serverless adoption, domain-first thinking is a necessary precursor to serverless-first thinking. Understanding the problem you are trying to solve is crucial. In start-ups or small-scale businesses, the business domain or problem may be clear and concise. However, this isn’t always the case in larger enterprises. While most enterprises operate in one domain—retail, hospitality, insurance, gaming, toys, etc.—bigger ones often have multiple domain areas. For example, Microsoft sells laptop computers and cloud computing services, and Amazon runs a retail business and Amazon Web Services.
Going deep into domain-driven design is beyond the scope of this book. A good resource with practical examples is Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy by Vlad Khononov (O’Reilly).
As you distill things further and break your business domains into subdomains, you identify the bounded contexts (see Figure 2-3 for an example). A bounded context is a boundary within a domain where a particular domain model applies. It reveals distinct characteristics and interacts with other bounded contexts via well-defined communication mechanisms such as APIs.
Figure 2-3. An ecommerce domain with subdomains and bounded contexts
Answering the following questions becomes easier when you get to this level:
- Who is responsible for protecting the domain boundary and implementing the domain logic?
- How will you safeguard the domain boundary to control the information flow into and out of that domain?
- Within a guarded boundary, which technology is apt to implement the business logic?
Once you’ve mapped out your subdomains and their boundaries, you need people who are well versed in each subdomain and speak the common business (ubiquitous) language used by the domain experts and business stakeholders. These people/teams must be aligned to focus on one thing and work together with a single purpose. This, then, is the starting point for thinking about the team structure.
The two-pizza team rule at Amazon stipulates that a team should be small enough to be fed by two pizzas. According to founder Jeff Bezos, smaller teams collaborate better because there are fewer communication links between the members. This in turn allows them to move faster with development and releases. This approach requires removing silos and giving teams end-to-end visibility of their products—that is, an ownership culture.
