How to Structure a Tribe

What is Domain Driven Design?

Microservices have a symbiotic relationship with domain-driven design (DDD) — a design approach where the business domain is carefully modeled in software and evolved over time, independently of the plumbing that makes the system work. I see this pattern coming up more and more in the field in conjunction with streaming as well as search capabilities. Everybody is talking about creating an agile and flexible architecture with microservices, a term that is used today in many different contexts. Although microservices are not a free lunch, they do provide many benefits, including decoupling. Decoupling is the process of organizing a system around business capabilities to form an architecture that is decentralized.

  • Agree on a language
  • Express it in shared models
  • Embrace complexity
  • Separate models in contexts
  • … and evolve them continuously
  • Concurrency: ensuring users can work in parallel without un-necessarily affecting each other
  • Complexity: large complex aggregates or asynchronous processes (often necessary for Eventual Business Rules) can increase maintenance costs and reliability of software applications
  • Performance: optimizing the responsiveness of the system by not having to load and save large data payloads from the database

Business-Led Pace Layering

I am inspired by MuleSoft API-Led connectivity pattern which also helps me to use to make a proposal later in this post on how to structure a tribe following DDD and Pace Layering.

What is Connectivity Pattern?

In simplistic terms, API led connectivity pattern is a way to classify and build the different types of APIs used in an enterprise — while specifying the high level functionality they are expected to implement. There are three main categories (or layers) of APIs in the API led connectivity pattern:

  • Process APIs — These APIs interact with and shape data within a single system or across systems (breaking down data silos) and are created here without a dependence on the source systems from which that data originates, as well as the target channels through which that data is delivered.
  • Experience APIs — Experience APIs are the means by which data can be reconfigured so that it is most easily consumed by its intended audience, all from a common data source, rather than setting up separate point-to-point integrations for each channel. An Experience API is usually created with API-first design principles where the API is designed for the specific user experience in mind.
  • Increased re-usability of APIs (only one API per the intended usage)
  • Clearly outline the key life cycle elements of the API like Owner, frequency of change
  • Identify operational and monitoring requirements

A bit of Change

Before we get into using DDD and these layering, I am going to change the layers a bit into following model, I will give more example later

  • Process Microservices
  • System Microservices

Structuring Tribe using DDD and Business-Led Layering

The Spotify model is a people-driven, autonomous approach for scaling agile that emphasizes the importance of culture and network, also helps you to scale up your engineering teams. It has helped Spotify and other organizations increase innovation and productivity by focusing on purpose, autonomy, mastery, communication, accountability, and quality. The Spotify model isn’t a framework, as Spotify coach Henrik Kniberg noted, since it represents Spotify’s view on scaling from both a technical and cultural perspective. It’s one example of organizing multiple teams in a product development organization and stresses the need for culture and networks.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store