Practical DDD, Part 1 — Setting The Right Foundations

Before we begin — I wrote this blog post, yours truly Hila. But the refinement, specific wording, and the available content around this topic in Augury are generated by a group of remarkable people, including me :), Oded, Nadav, Eyal, and Assaf.

Prologue

We all know the story, a company reaches the state of hyper-growth, and it all goes to hell — gazillion microservices, micro-frontends, databases, etc. New development teams appear every quarter and we onboard more people than ever before.

The birth of the architecture forum

‘Conway’s law’ claims that multiple authors must frequently communicate with each other for a software module to function. Therefore, the software interface structure of a system will reflect the social boundaries of the organization that produced it. We optimize to reach velocity, autonomy, and business impact by enabling team ownership on architectural components.

To achieve all of that, we need to have alignment between teams, fleets (R&D group), and sometimes even cross R&D. Augury has decided to create a new persona in each R&D: the architect. An architects’ primary responsibilities are:

• Understand and impact the product strategy by creating the architectural vision, guidelines, and roadmap.
• Mentor and guide SW engineers, and help them increase their craftsmanship skills.
• Continuously strive for alignment between team structure and architectural components, generate clear interfaces, boundaries, and terminology to enable autonomy and continuous improvement.
• Continuously improve our design and delivery processes with the Product & R&D teams to face current/future challenges from Augury’s scale.

If I needed to define a one-liner, I would say, “Architects are agents of change, not decision-makers”. If our architects are our ‘Conway’s law’ agents, they need a designated headquarters. And this was the birth of the architecture forum. The architecture forum is where the architects come together and formalize what we see happening in the fleets. We have a weekly meeting to discuss topics, generate content, and raise issues.

In this picture, you can see us during our google Meet meetings as we are working in a hybrid model.

The tale of DDD in Augury

Once upon a time, there was a backend developer named Oded. Being an Augury veteran, Oded got the exciting mission of structuring our architectural guidelines. Well, ‘once upon a time’ is one year ago. When Augury started to scale as a company, it became clear that we needed to act asap to avoid reaching the point of no return. We needed to work before our R&D team became too big, and it would become too tough to propagate new ideas and conventions.

So our “DDD v1” playbook was created and was named the “Augury architecture playbook”. Oded talked to multiple companies. The approach was to collect information and embrace what works for our specific use case. We customized definitions for our DDD building blocks and outlined various rules and guidelines.

We used this playbook for almost a year but found that it was hard to navigate as it was packed with content. You needed some familiarity with it in order to find the answers you were looking for. The result was that only a small group of people mastered the guidelines. We wanted to break the ‘chain of advice’ and find a better way to propagate this knowledge to the different R&D groups.

Making it practical — it’s all about the propagation

As a growing company, this is not the first time we have implemented a paradigm shift regarding how to propagate information and knowledge. The first step truly started when Augury shifted to multidisciplinary product squads that executed a concept called “developer in the center”. This approach focused mainly on autonomy by increasing product involvement and reducing hand-offs in the delivery process. It’s a long story, and I can point you out to a good session given by Assaf on the topic (in Hebrew, sorry).

So once we understood that the current situation was harming the squads’ autonomy and that we had created a process that is not sustainable or scalable from an architectural standpoint, the architecture forum went back to the drawing board to define what we are optimizing for.

The guidelines should be -

• Short and well-scoped — should be easy to find and understand, making it easy on the eyes and with as less cognitive load as possible.
• Referable — should be easy to refer to from inside a DR, making it easy to refer to a specific topic from inside a design using links, removing the need to reopen conversations on the same issue repeatedly.
• A live document — should be easy to comment on and update when guidelines are updated as we improve our understanding of our use cases and domain.

So we decided to break down the “book” and instead create a definition dictionary that will be complemented with “architectural topics”. An “architectural topic” is a pattern or a question that we would like to deep dive into and have specific guidelines. We decided on this format because we wanted a simple way to share the particular guidelines to unique questions that we continuously see arising in design reviews. It should be as simple as adding a link.

After our main topics were ready, we decided to generate a series of open sessions with all of R&D — “Augurian Architecture”. In each session, we focus on a topic and generate conversation around the prominent use cases and significant dilemmas. The sessions are one hour long when 20 minutes are dedicated to definitions. The remaining 40 minutes are aimed at open conversation in which participants share different use cases from our real-world problems and design reviews. This format enabled us to:

• Engage as many people as possible in this process.
• Be able to bring examples from all of R&D and not just the domain of the person preparing the content.

How to structure an architectural topic

We created a template -

1. Relevant links
2. A short description of why this architectural topic exists
3. A list of “when-> then”s

• Each architectural topic may have one or more central questions
• Each question will start with the word “when”
• Each question may have one or more “when->then”
• Each “when->then” represents a use case in a specific question

Example (using definitions below):

Architectural topic name — aggregate & bounded context microservices.

Question — when to create a new aggregate microservice?

“When->then” — when “we are adding a business unit with command (CRUD) operations” then “consider creating it as a new aggregate microservice”.

The example might seem out there right now, but in future posts, we will drill down into architectural topics and their “when->then”s.

DDD vs. Microservices — Logical vs. Practical

DDD gives us a lot of definitions and logical patterns that enable us to define our architecture and team structure. However, these logical patterns refer to the technical aspects of the business. It’s important to remember that microservices are an implementation tool that will enable us to achieve these logical patterns.

A microservice is a technical implementation that (hopefully) implements these capabilities:

• Highly maintainable and testable
• Loosely coupled with other microservices
• Highly cohesive
• Independently deployable
• Organized around business capabilities
• Owned by a small team

For example (using the definitions below), An Aggregate or Bounded Context is derived from DDD. Meaning they are logical patterns that derive from modeling our business, and we can represent an aggregate as an aggregate microservice, the same for bounded context.

Fundamental definitions

Domain-Driven Design — ‘DDD’ is a Software Design approach that stands for Domain-Driven Design, focusing on modeling software to match a business domain according to inputs from that domain’s experts. The objective of DDD is to improve communication and structure between different fields of expertise And build a common language that everyone in your team can understand.

Bounded Context (BC) is an aggregation of related areas\business requirements of\in our product. Each model/business unit has a specific meaning that is unique and agreed upon in the same BC (ubiquitous language). As our product evolves, more BCs are born. In DDD, a BC contains one or more Aggregates.

An Aggregate is a cluster of associated objects that we treat as a unit for data changes. Also frequently known as the business model.

A View-Service (a.k.a B.F.F) is a centralized place to implement business logic aggregation and/or data enrichment from one or more aggregates optimized for a functional product area (UI).

A Cross-Cutting concern provides commonly-used capabilities to different aggregates in the system. It is not oriented to a specific product area by design and should be able to support various aggregates to fulfill their day-to-day tasks.

Communication Channels are the way we communicate between different parts of our system. The communication can be internally within my domain or external to other domains, synchronously or asynchronously, fetch read-only data or change the data state.

So what did we have, and what’s coming next

In this blog post, I talked about our ongoing journey with DDD, why we created the architecture forum, and how we see the architect’s role in Augury. Afterward, I wrote about some fundamental definitions in DDD that can be interpreted for different types of microservices or communication channels.

Basically, this post summarizes our first session in our “Augurian architecture” series. As you might have guessed, more blog posts are to come. They will focus on specific architectural topics that we have found challenging because they have repeatedly created open discussions and questions in our design reviews.

As I wrote in “what we are optimizing for with our guidelines”, these are live documents according to our perspective. We will love to hear if you have some input on these topics!

For Part 2, click here