Domain Driven Development
Before learning a new subject, I often ask myself some questions to improve my learning process. As usual, let’s start questioning together😊 In this post, I tried to explain domain-driven development as much as I could.
Layers? Should I use layers in a software project?
Imagine that you created one .Net Core project in which you put all your files under one folder. In the beginning, you may not struggle to find any file that you need to modify. However, after a long time, there might be hundreds or thousands of files in that folder. So, managing all files will become difficult. That’s why you should have separated them depending on responsibilities or other criteria. One possible solution is the Layered Architecture. Each layer contains objects related to a particular concern. The number of layers varies depending on the project needs and boundaries. We mostly see the following layers: Domain, DataAccess, Application(Business), and Presentation.
Even we separate concerns, we still might face some problems during software development. So, I researched some of the reasons that affect the software development process.
Some of the reasons that software projects end up failing
- Lack of ubiquitous Language
- Lack of Communication
- Unclear project boundaries
- Integration Issues
- Unrealistic or mismanaged timelines
- Lack of understanding needs
There are several methods to avoid these failures. For instance, design thinking might help us to find out the source of the problems and to find differents solutions in a limited time. Now, it’s time to learn DDD!
Domain Driven Development
Domain-Driven Design is an approach to software development that centers the development on programming a domain model that has a rich understanding of the processes and rules of a domain. — Martin Fowler
DDD was first introduced by Eric Evans to solve the complexity of software development.
Domain
The center of the domain driden development is the Domain layer. A well designed and planned domain decrease problems in the further steps of the software development process. The domain model should be isolated, reusable, designed loosely coupled…
A sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software.-Eric Evans
Ubiquitous Language
As i said above, the lack of ubiquitous language has bad effects on our projects. So, having a common language decreases misunderstandings, raises the quality of products and removes ambiguities.
Bounded Context
Bounded Context is a semantic contextual boundary. This means that within the boundary each component of the software model has a specific meaning and does specific things.©Vaughn Vernon. Domain-Driven Design Distilled.
Context Mapping
Context Maps lets us understand the relationships between the different bounded contexts. Understanding the relations between the different bounded contexts let us build a domain correctly.
Strategic Domain Driven Design
The strategic design focus on the ubiquitous language, the Bounded contexts and Context Maps.
Tactical Domain Driven Design
The tactical DDD is the way that we design the system using different design patterns and resources.
Shared Kernel
As the name suggests, ıt’s one part of the project that is used by several bounded contexts.
Customer/Supplier Development Teams
This is the case where one bounded context is dependent on another bounded context.
Conformist
There is a relationship between two bounded contexts, where the upstream has no interest in supporting the downstream.
Anti-corruption Layer
This is also describes a relationship between two bounded contexts.
The public interface of the anticorruption layer usually appears as a set of services, although occasionally it can take the form of an entity. -Eric Evans
Seperate Ways
if there is no relationship between two contexts, we separete them.
Domain-Driven Design: Tackling Complexity in the Heart of Software 1st Edition- by Eric Evans
Do let me know your view on this 🙂 See you next time!
