Get in touch


We use HubSpot CRM to process and manage contact and information requests. Please accept the "Functional Cookies" and reload the page to load the contact form.

Services / Academy / Software development & architecture

Domain-Driven Design

Tactical Software Architecture

0.5 days Remote
Inquire now

Challenges

"The heart of software is its ability to solve domain-related problems for its user?" (Eric Evans)

In a software development project, it is vital for developers to understand the problem domain in order to abstract it in an understandable and potent domain model in the software. Therefore, developers, domain experts and users need to speak a common language. These are principal ideas of Domain-Driven Design. Ideally, code is aligned with the reality of the problem. This requires conversations with users and domain experts. Using certain building blocks and a well separated layering in the software is the key to get maintainable and understandable code. Also, while new developers understand the code, they will also understand the (abstraction of) the problem domain.

Goal

Domain-Driven Design - Motivation

​​Domain-Driven Design is a family of software and architecture patterns and best practices. It is also a process that aligns the code with the reality of the problem domain and keeps developers and domain experts working together. It has proven to be really helpful when you want to write maintainable software for a problem space that has a certain complexity. So if you need to build software, that is strategically relevant for your business – and that is likely to change and evolve over time – you should be familiar with the ideas and building blocks of Domain-Driven Design.
​​ 
​​A software that is modeled close to the real problem domain is much easier to grow and adapt with it: In fact, the difficulty in adding new features remains constant and relatively small. And if the solution is properly broken apart along bounded context lines, it is easy to extract parts of it into microservices for example.
​​ 
​​Domain-Driven Design goes hand in hand with “Clean Code” and Hexagonal Architectures and in your hands-on trainings we integrate these approaches and tell from the experience we have from real project implementations. Furthermore, DDD increases security (security by design) and testability of your software a lot.

Training goals and concepts

The training starts with a reflection on common challenges in software development and where DDD practices are appropriate to address these challenges.

Then an overview of tactical DDD building blocks and pattern is given and practical implementation know-how for them is provided. In order to be able to follow the training well, we use a sample domain, which we follow step by step and discuss practical code examples (in Golang).

After the training you are prepared to:

  • Reflect where and why to apply DDD practices
  • recognise and start using the basic DDD building blocks
  • Implement applications with clean layering and know some best practices
  • Discuss the relation between namespaces, modules, aggregates and bounded contexts
  • Be aware of typical smells

Content

  • Introduction to DDD:
    • Motivation and Context. Clarification of terms.
    • When to use DDD and when not?
    • Whats the focus of “Strategic DDD” and “Tactical DDD Patterns”. What are Bounded Contexts?
    • What is a potent “Domain Model“? What are representations and artefacts?
  • Introducing the example domain "Hackerando"
  • Application Architecture: Benefits of a “technology free domain model”. Separation of concerns and typical layerings. Concept of "ports and adapters" and hexagonal architecture.
  • Tactical Patterns Overview and Building Blocks
    • Overview of Building Blocks and Design Pattern
    • Value Objects in Detail
    • Entities in detail
    • Domain Services in Detail
  • Design Patterns
    • Modeling the Domain
    • General Principles and Goals
    • Aggregates, Aggregate Roots and Invariants
    • Repositories
    • Repository Implementation Examples
    • Factories and Reconstitution
    • Lifecycle Overview 
    • Domain Events
    • References and why to reduce them
  • Implementing DDD
    • Bounded Context, Modules, Namespaces.. How do they relate?
    • How can an application with modules be structured? 
    • Typical DDD Smells

Organizational information

  • Duration: 4 hours
  • Language: English or German, depending on preference
  • Location: Online
  • Group size: from 5 to 15 participants
Daniel Pötzinger

Our trainer: Daniel Pötzinger

Daniel Pötzinger has many years of experience in the development and architecture of Enterprise Web Applications. He has worked with many great self-organized agile teams and knows how collaboration and mutual inspiration – together with the right technologies and patterns – makes software projects successful and solving challenges fun. In addition, Daniel has comprehensive knowledge about how to establish DevOps and Continuous Delivery practices in IT organizations.
 
At AOE, Daniel has provided consulting services and helped implement more than 100 Enterprise projects for such renowned clients as Deutsche Telekom, congstar, Rovio, Cisco Webex, QVC and VMware.

Stefan Rotsch

Our trainer: Stefan Rotsch

Stefan Rotsch has many years of expertise in the development and architecture of complex web applications. As a Solution Architect at AOE, he analyzes and designs software projects in the telecommunications sector and accompanies customers and development teams from conception to successful go-live. He shares his experience in the field of agile software development with great success in various presentations at conferences and bar camps.