Domain-Driven Design
Eric Evans introduced Domain-Driven Design (DDD) in 2003. Today, Domain-Driven Design is popular. It is a sought-after skill in the industry. So, what is it about?
I recommend you these two books to understand DDD. First, of course, the book written by Eric Evans, the blue book, Domain-Driven Design: Tackling Complexity in the Heart of Software. Second, Domain-Driven Design Distilled by Vaughn Vernon.
In short, I can say that DDD is about design. Yeah, just simply like that. By design, we can understand the business, and the complexity of the software that we will code, and it gives us the paradigm about the entire journey at the beginning.
What design? Just focus on designing the domain, the domain layers. We don't need to design the application or infrastructure layers. So, the design is driven by a domain. A domain is a sphere of knowledge, influence, or activity. I can say that the domain is a business for short.
We design the diagram first. It can be both context and class diagrams. We design together. Developers, QA, and most important domain experts. Domain experts are experts in the domain. They know what the business is about. Designing it together is also an important part. It could make a language for all. Just one language is used by developers, QA, and all teams. So, developers can understand what domain experts / businesses say, and other teams too because developers use the language as their naming convention, QAs use it for scenarios, etc. This is called Ubiquitous Language. Using one language like this can reduce miss communication potential.
Strategic Design
The goal of Strategic Design is to understand the context. Are there any bounded contexts? What components are in the context? Are those components out of context?
Honestly, I prefer Context and Data Flow Diagrams because it makes more clear. But, that combination will make the diagram wider because that includes infrastructure layers such as databases which are not compatible with DDD practice that focus only on the context or domain. But, Context Diagram only is fine. That was just an opinion from a developer's point of view.
Tactical Design
I can say that Tactical Design is another level from Strategic Design which is more detail. We break out components of the context to be Aggregates, Entities, and Value Objects. That is the basis of Tactical Design. We don't need to design more details than that. Just boxes with Ubiquitous Language instead of class diagrams are enough.
Honestly, I prefer more details than that. I prefer class diagrams instead of only boxes. I prefer adding Repositories, Services and even adding application or infrastructure layers to the diagram. But, it will lead complexity of the diagram which is maybe not important for non-technical teams such as domain experts.