====== Alternatives to UML2 notation for domain driven design ======

By Chistobaev Daniil (dachistobaev@edu.hse.ru)

===== Introduction =====
Domain-Driven Design (DDD) is a software development approach introduced by Eric Evans ((Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software.)). It revolves around the idea of constructing software with a strong focus on comprehending the specific problem, or 'domain,' it aims to address. This methodology highlights the significance of ensuring that everyone involved in the project shares a common understanding of this domain. Such shared understanding helps align the software closely with the core concepts of the problem it's meant to solve. A fundamental aspect of DDD involves creating visual representations of these domain models. These representations are akin to diagrams, aiding individuals in visualizing and comprehending how various components of the domain are interconnected. Typically, practitioners employ a notation known as Unified Modeling Language 2 (UML2) for this purpose. However, it's worth noting that UML2, due to its complexity, can sometimes hinder effective communication and hinder a complete grasp of the domain.

===== UML2's Challenges: Alternative Representation Methods =====
UML2 is a popular tool for designing software. However, it has its challenges. Its wide range of symbols can be confusing for beginners, making it hard to learn quickly. While it's meant to fit many situations, this broad approach can miss specific details important for some projects. Also, because it's so detailed, some developers might spend too much time on minor aspects. Lastly, its complex diagrams can be tough for non-tech folks to grasp, leading to communication gaps between teams. Considering these challenges, it's worth exploring alternative methods of representation.
===== Alternative Notations =====
While UML2 offers a comprehensive approach to modeling, it can sometimes be overwhelming, especially when the focus is on domain-specific nuances. This has led practitioners to explore other notations better tailored for DDD. Here's a look at some of the most prominent alternatives:
=== Domain-Specific Languages (DSLs) ===
Domain-Specific Languages (DSLs)((Fowler, M. (2010). Domain Specific Languages. )) are special languages designed for specific types of tasks. Unlike general-purpose languages that can do many different things, DSLs are created to solve problems in one particular area. This narrow focus makes them easier to use and understand, often simpler than broader languages like UML2.

The big benefit of DSLs is that they match how experts in that area think. By using the same concepts and ideas from that domain, DSLs make it easier for developers to talk to each other and to people who are experts in that field.

**Features of DSLs:** 

Made for One Thing: DSLs are languages made to do one specific thing really well. They use terms and rules that fit that topic or area perfectly.

Easy for Experts: If you know the topic well, picking up a DSL can feel natural and straightforward.

Less Mistakes: Since DSLs are made for just one thing, there's less room for errors that you might get in broader languages.

**Why Use the DSLs for DDD?**

Shared Language: In DDD, everyone (like coders and business experts) needs to speak the same language. DSLs can help with this because they use terms that fit the business topic.

Clear Business Rules: DSLs let you show business rules clearly, without getting lost in technical details.

Stays on Topic: With DSLs, you can focus on the business without getting distracted by unrelated tech stuff.

Flexible: As you learn more about the business, you can easily tweak or add to the DSL.

=== C4 Model ===
The C4 Model, which stands for "Context, Containers, Components, and Code ((Brown, S. (2018). Software Architecture for Developers: Volume 2. C4Model.com.))," is a progressive framework designed to visualize and describe software architecture. It breaks down the architecture into four different levels of abstraction:

**Context**: Describes the high-level goals, stakeholders, and external systems interactions.

**Containers**: Focuses on applications and services, explaining how they interact and their responsibility areas.

**Components**: Delves deeper into the architecture, detailing the key classes or components within containers.

**Code**: The lowest level of abstraction, it concerns itself with the source code level.

**Features of C4 Model:** 

Layers: The C4 Model is like a zoom lens. You can look at the big picture (Context) or zoom in to see details (like Code).

Clear Symbols: The C4 Model suggests using certain symbols to represent things like users or parts of the software. This makes diagrams easy to understand.

**Why Use the C4 Model for DDD?**

Setting Boundaries: The Context layer helps you see where the software fits in the bigger picture.

Showing Details: Layers like Containers and Components let you visualize the important bits of the business.

Connecting Everyone: By showing everything from big goals to code details, the C4 Model helps everyone - from business people to coders - understand and talk to each other.

Easy to Update: As you learn more, you can easily change and refine the model.
=== ArchiMate ===
ArchiMate, developed by The Open Group((The Open Group. (2013). ArchiMate® 3.0 Specification. The Open Group.)), is an open and independent modeling language for enterprise architecture (EA). It offers a coherent and integrated approach to describing, visualizing, and analyzing different architecture domains, from business to information to technology layers.

**Key Features of ArchiMate:**
Multi-layered Approach: ArchiMate categorizes its elements across three primary layers - Business, Application, and Technology. These layers enable architects to capture and describe enterprise functions from a holistic perspective.

Standardized Notation: One of the significant benefits of ArchiMate is its standardized notation. Unlike UML2, which is quite vast and generalized, ArchiMate's set of symbols is tailored for enterprise architecture, ensuring a consistent representation and understanding.

**Why ArchiMate for DDD?**

For projects that touch upon the broader spectrum of enterprise architecture, including business processes, IT systems, data flows, and more. Its structured methodology and domain-specific notation make it particularly apt for capturing intricate relations and dependencies within the domain.
=== Event Storming ===
Event Storming is a dynamic and collaborative modeling method that emphasizes domain events as its primary tool to understand and map out intricate business domains((Brandolini, A. (2013). Introducing Event Storming.)). In this technique, participants, which often include a mix of domain experts and developers, use colored sticky notes to represent different domain events and their interactions.
Key Features of Event Storming:

Everyone Joins In: People from different roles like experts, coders, testers, and business folks come together. 
Using Sticky Notes: They use different colored notes to map out events and other details. This makes it easy to see the whole process and find any issues.

Quick and Repeated: Instead of trying to make everything perfect at once, they quickly map out ideas and then keep improving them. It's all about learning and adjusting.

Talking Matters: A big part of Event Storming is the discussions people have. It's not just about the notes but also the insights and ideas they share.

**Why ArchiMate for DDD?**

When you want a deep dive into a project and uncover all its parts, especially the tricky bits, Event Storming is a great matc


===== Conclusion =====

The search for efficient domain modeling and communication in DDD projects requires the investigation of UML2 notation alternatives. Although UML2 offers a uniform approach, its complexity frequently overshadows its usefulness. DSLs, the C4 Model, ArchiMate, and event storming are among alternatives that each provide promising ways to encourage efficient domain modeling and more open stakeholder engagement. These alternatives are essential resources for a variety of situations because each one has particular advantages. Personally, I would incline toward the C4 Model due to its structure and emphasis on layered comprehension. The final decision among these would, however, mostly depend on the particular requirements and context of the project at hand.

===== References =====
1. Domain-driven design: рецепт для прагматика https://habr.com/ru/companies/jugru/articles/440772/

2. On the Relationship between Domain-Driven Design and Domain-Specific Languages https://www.linkedin.com/pulse/relationship-between-domain-driven-design-languages-markus-voelter

3. Модель C4 https://ru.wikipedia.org/wiki/%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_C4

4. Чем полезен ArchiMate аналитику https://systems.education/archimate

5. Моделирование микросервисов с помощью Event storming https://habr.com/ru/companies/oleg-bunin/articles/537862/