Working with DDD - Domain, Model and Language

There are a lot of concepts that is important for DDD. The most important ones are the Domain, the Model and the Ubiquitous Language.

Domain

A sphere of knowledge (ontology), influence or activity. The subject that the user is working a program on the domain of is software. The domain in DDD is the problem space. The corresponding solution space is called the model.

Model

A system of abstractions that describe selected aspects of a domain and can be used to solve the problems associated with that domain.
With DDD, we are looking to create models of the domain. Things which often places great effect at the beginning of a project, such as persistence, user interface and protocol. Model does not mean a graph or set of graphs e.g. UML. Charts are useful, but they are not the model, just different views of the model. The model is one that we choose to implement in software, represented in the code used to construct the system. The code itself is the model.
This gives certain expectations of the code. It shall be easy to understand and read. If the domain experts can understand a snippet of code describing their domain, the room for error shrinks. The standards set by Robert C. Martin in Clean Code is one way to accomplish this.

Ubiquitous Language

A language built around the domain model and is used by all team members to connect all activities the team with the software.
This does not exclude the use of diagrams, symbols and text analysis. These are important tools for finding the model, and describe it before it gets into the code. Texts and informal sketches is a good starting point. We do not need any special design model or specific sets of symbols. This is because we are starting from the domain, the reality, and have to describe it in a way that is shared by developers and those who order the application, the domain experts. It is therefore extremely important to have a common description of reality and a ubiquitous language. This work is the basis for the whole architecture.

Comments

Balancing Present Needs and Future Growth

In software development, traditional project planning often emphasizes immediate needs and short-term goals. However, Bentoism, which stands for "Beyond Near-Term Orientation," provides a multidimensional framework that can improve software project planning. It advocates for a balance between short-term achievements and long-term sustainability, considering both individual and collective impacts. Technical debt and architectural debt are inevitable challenges that teams must navigate. If managed properly, these debts can help long-term sustainability and growth. Bentoism, with its forward-looking and holistic perspective, offers a nuanced framework for handling these challenges while promoting continuous improvement. Understanding Bentoism Bentoism, inspired by the structure of a bento box that contains a variety of foods in separate compartments, encourages a broader perspective in decision-making. It promotes consideration of 'Now Me' (current self-interests), ...

Digital Dialectics: A Marxist Exploration of Technology and Class in the Software Industry

In this blog series, we discussed various aspects of programming and technology from a Marxist perspective. Here's a summary: Marxist Analysis of Programming and Technology: We explored several critical aspects of Marxist theory applied to programming and technology, including the means of production in software development, class struggle and labour relations, the commodification of software, alienation in the tech industry, and the digital divide and technological inequality. Dialectical Materialism and Base and Superstructure: We delved into applying Marx's dialectical materialism to technology development, analyzing how technological advancements lead to societal changes. We also discussed the base and superstructure model in the context of the digital age, focusing on the technical infrastructure and the evolving social and cultural norms. Class Struggle in the Software Industry: We examined the dynamics between different groups in the tech industry, including tech compa...

Software Projects as an Orchard

This blog is named The Sourcerers Orchard. The title is intended as a pun about source code and the orchard as an analogy between software development and handling an orchard. Creating a new orchard is an endeavour that blends the art of gardening with science. The same could be true for software development. We often talk about software as an industry, and this mindset harms our work. We are not an industry; we do not repetitively produce the same unit at an assembly line. We grow new things in a partly unpredictable world. Systems like SAFe are born in industrial thinking, like modern mercantilism, focused on numbers, not growth. We need a new way of thinking, to make high quality software instead of failing production lines. Planning Your Orchard Embarking on creating a new software project is akin to cultivating a thriving orchard from the ground up. It’s a journey that requires patience, dedication, and a strategic approach to nurturing growth and overcoming challenges. Let’s expl...

the Sourcerers Orchard

Search This Blog