Over a million developers have joined DZone.

DDD With .NET Core for Beginners — Concepts

DZone 's Guide to

DDD With .NET Core for Beginners — Concepts

Learn about the core concepts of Domain Driven Design for .NET Core applications to learn how to design them effectively, like bounded context and continuous integration.

· Microservices Zone ·
Free Resource

Domain Driven Design (DDD) is an approach to software design that relies on the concept of Domain (well, pretty obvious!). But what does it mean, Domain?

"A domain is a field of study that defines a set of common requirements, terminology, and functionality." - Wikipedia

DDD aims to ease the creation of complex applications by connecting the related pieces of the software into an ever-evolving model.


Eric Evans, who introduced DDD with his book Domain-Driven Design: Tackling Complexity in the Heart of Software, defines a set of basic concepts to introduce us to DDD.

Bounded Context

The setting in which a word or statement appears that determines its meaning.

When we work in a relatively large software project many models are in play. If we don't manage carefully teams working independently can solve similar problems in different ways and that can lead to code that is harder to understand or unreliable.

We should explicitly define the context within which model applies. We set boundaries and physical manifestations such as different database schemas or code bases. We define team and process rules to define the use of specific parts of the application.


A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain. If the design does not map to the domain model, that model is of little value, and the correctness of the software is suspect.

Design a portion of the software system to reflect the domain model in a very literal way so that mapping is obvious.

Ubiquitous Language

A language structured around the domain model and used by all team members to connect all the activities of the team with the software.

Communication is very important on a team and we must ensure that a clear definition of specific terms is available to everyone. Day-to-day communication happens to be disconnected from the terms used in the code and that can lead to misunderstanding.

Commit the team to exercising a uniform language relentlessly in all communication and in the code. Resolve confusion over terms in conversation, in just the way we come to agree on the meaning of ordinary words.

Continuous Integration

Once a bounded context has been defined, we must keep it sound. When multiple people work on the same code it's hard to keep everything coherent and functioning. It's easy to change or break an existing behavior of a part of the software as a side-effect of a feature development or bugfix. We have to create and work with a process that frequently merges all the code, runs automated tests to check problems as soon as possible.


With the above concepts, we've done the first steps in the DDD world. We've seen the theoretical foundations of this design technique.
In the next posts, we'll talk about the building blocks that are a key part to create our software solution with DDD.


DDD Wikipedia

Domain-Driven-Reference 2015 by Eric Evans

ddd ,.net core ,microservices ,domain driven design ,bounded context ,tutorial

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}