Topic Backlog for

Certified Professional for
Software Architecture^®
Expert Level

Over time, software projects typically become more cumbersome, fragile, and error-prone. The reason often lies in too many dependencies, poor cohesion, and high coupling. Domain-Driven Design (DDD) promises a solution to this problem.

However, DDD is more than just the cutting of components. Much of it is often overlooked, thus many of its strengths cannot be utilized: Deep Insight, Break Through, Supple Design, Large Structures.

Furthermore, DDD is a very agile approach, which, if implemented correctly, has a strong impact on workflows and company structures.

The processing of the topic should demonstrate the problems that can be solved with DDD and what can be achieved with DDD.

However, the impact on the company should also be shown, or why DDD can fail. What conditions must be met for DDD to be beneficial?

The topic should be examined from the perspective of an organization, management, software developers, and users, among others.

Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Pearson ITP.

Vernon, V. (2013). Implementing Domain-Driven Design. Pearson ITP.

The topic should be handled by a group of 3-5 people.

Documentation is just as important in software development as it is unpopular. In the past, and under the influence of the waterfall model, often unwieldy paper deserts were created. In agile software development, on the other hand, documentation is often seen as a burden and unnecessary. New media and the recognition of the importance of clean architecture documentation shed new light on documentation.

What are the quality characteristics of good architectural documentation, and how are these insights introduced into a project? What experiences with the introduction and daily use can be passed on to other teams? What difficulties arose and how were they dealt with? Where are there still unresolved questions and problems?

The following questions should be addressed:

Zörner, S. (2021). Documenting and Communicating Software Architectures. Hanser Publishing

Starke, G. & Hruschka P. (2022). Arc42 in Action: Practical Tips for Architectural Documentation. Carl Hanser Publishing

Homepage of the ADR GitHub organization. https://adr.github.io/

Brown, S. The C4 model for visualising software architecture. https://c4model.com/

The topic should be handled by a group of 3-6 people.

NoSQL databases are no longer a novelty. In many projects, they are standard, but in many others, they are not.

For those who have only dealt with relational databases, it’s often hard to imagine how the use of NoSQL databases can be successful:

This topic is of interest to architects, developers, operations, DB administrators.

These questions should be answered:

Other topics in this context include Event Sourcing, Eventual Consistency, Scalability, Fail-Safety, Licenses, or BASE.

A few successful practical examples with tips and tricks would be helpful.

Fowler, M., & Sadalage, P. J. (2012). NoSQL Distilled. Pearson Education.

The topic should be handled by a group of 3-5 people.

Interest in Event-Driven Architectures (EDA) didn’t just start with the publication of Vernon’s book "Implementing Domain-Driven Design," featuring a foreword by Eric Evans. Event-Driven Architectures offer a high degree of flexibility in software, whether in program execution or data capture. EDAs are already being successfully used in many places. Cloud providers offer solutions, and more and more frameworks are coming to the market. Monitoring, Business Intelligence (BI), and many other areas make use of EDAs.

Event-Driven Architectures help create flexible systems that can adapt to changes and make real-time decisions. Events are captured as soon as they occur from event sources such as Internet-of-Things (IoT) devices, applications, and networks, allowing event producers and event consumers to exchange status and response information in real-time. In this context, the concepts of Event Sourcing and CQRS are often discussed, presenting further challenges but also promising exciting advantages.

These questions should be addressed:

Vernon, V. (2013). Implementing Domain-Driven Design. Pearson ITP.

Domogalla, M. (2022, April 21). Software-Architektur.tv: Software Architecture with Events, Event Sourcing, and CQRS. Developer. https://www.heise.de/news/software-architektur-tv-Softwarearchitektur-mit-Events-Event-Sourcing-und-CQRS-7061126.html

The topic should be handled by a group of 3 to 7 people.

Large software systems are typically implemented by multiple development teams. While feature teams have become established in backend development, in many projects the frontend is developed by a single team. However, the concept of microservices is increasingly being adopted in frontend development as well: Independent teams work on a functional frontend component and can develop and deliver their component independently of other teams. There are various methodological and technical approaches to implementing this so-called microfrontend architecture.

The following questions should be answered:

The topic should be handled by a group of 3 to 5 people.

Machine Learning (ML) is increasingly evolving from fiction to an indispensable technology. Those who do not engage with ML early may find themselves left behind later. However, investing in it is very risky.

The application areas are diverse: construction, automotive industry, finance, government agencies, logistics, marketing. However, implementation requires new talents and raises questions. No one should miss out on this development.

In the context of digitalization or increasing competition, new solutions are needed where ML can offer good assistance. In the field of Business Intelligence or Big Data, new methods are needed where ML can be supportive.

The contribution should encourage finding an entry point into this topic.

There are many things to clarify:

The topic should be handled by a group of 3-7 people.

Markets are becoming more complex, and software in the business and technology sector is getting more complicated. This often necessitates companies to seek the solution for their software projects in a Microservices Architecture (µService).

µServices are usually implemented with Kubernetes (K8s). Kubernetes is a highly complicated and complex framework. Developers are often overwhelmed with its installation, use, and operation, leading to projects that can easily fail or become unprofitable. An intense exchange between roles in requirement management, architecture, development, testing, and operation is therefore necessary. Lack of agility and rigid structures in the company make things more difficult. Initial approaches exist in DevOps, but more will be needed.

Participants are to process the problems, approaches, and solutions from their projects and create a guideline.

Liebel, O. (2023). Scalable Container Infrastructures: The Handbook for Administrators (4th Edition). Rheinwerk Computing.

The topic should be handled by a group of 6-7 persons.

For over 20 years, UML has been considered the standard for modeling software systems. Other modeling languages position themselves either as lightweight alternatives (e.g., C4), as complete replacements, or for a specific application area or domain (e.g., BPMN, SysML, ArchiMate).

The use of modeling languages is not always popular. They are often seen as too complicated or cumbersome. Nevertheless, large projects cannot be implemented without modeling. Often too late, it is recognized that the interrelationships in the project are no longer comprehensible, and a suitable model could have helped here. It would have been even better to start modeling early on to promote communication in the project.

The working group should discuss the following questions and prepare the findings:

The topic should be handled by a group of 4-7 persons.

In recent years, there have been increasing voices claiming that the SOLID principles are no longer contemporary. For instance, in 2021, Dan North caused a stir when he claimed that every single SOLID principle was wrong. After some time, he followed up and proposed his so-called "CUPID-Properties" as an alternative:

The working group should clarify the following questions:

The topic should be handled by a group of 3-5 persons.