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

Evolution Of Programming Languages in an AI perspective

Programming languages are at the heart of possibilities in software development, evolving to meet the growing complexity of the problems we solve with computers. From the early days of machine code and punch cards to the modern era of high-level languages and AI-augmented coding, the journey of programming languages reflects humanity’s relentless pursuit of abstraction and efficiency. As artificial intelligence begins to reshape the landscape of software development, we are poised to enter an era of AI-powered programming languages—tools that will fundamentally change how programmers approach their craft. From Punch Cards to High-Level Languages The earliest programmers worked directly with machine code, encoding instructions in binary or hexadecimal formats. This labour-intensive process required an intimate understanding of the underlying hardware. Punch cards, though a technological marvel of their time, epitomized the low-level nature of early programming—tedious, error-prone, and ...

The Industrial Vs the AI Revolution

The transformation of society through technological revolutions has constantly fundamentally reshaped the labour structure. The Industrial Revolution, for instance, marked a profound shift in work for the labouring classes, moving them from farmers' fields and industries into factories. Today, the so-called AI Revolution promises to bring about a similarly seismic shift, not for manual labourers but for the office and intellectual workers who were once considered relatively insulated from mechanization. While the material and historical circumstances differ, the underlying forces remain strikingly parallel. Changing the Nature of Work During the Industrial Revolution, the mechanization of production displaced artisans and craftspeople, as machines took over tasks that had required years of training and skill. This was not merely a displacement of labour but a profound de-skilling of workers, whose tasks were broken into repetitive, machine-supervised steps. The labour force expande...

Yearly Educational Goals vs. Agile Team Learning

At this time of the year, employees often have their yearly reviews and set goals for the following year. From an agile point of view, this is an antipattern. The Agile methodology promotes continuous improvement and adaptation. This philosophy often needs to match this traditional approach of setting fixed yearly educational goals for developers. This discrepancy can be analyzed regarding how these educational strategies align with the interests of labour and management within the industry (as opposed to the orchard) and how they contribute to or alleviate the alienation and class dynamics inherent in the tech workforce. Yearly educational goals in software development typically involve predefined objectives that developers are expected to achieve within a set timeframe. While this approach provides clear targets and a sense of structure, it can be rigid and limiting in a field known for rapid technological changes and evolving project needs. Such goals may become quickly outdate...

the Sourcerers Orchard

Search This Blog