DDD – Part 1: Once upon a time…


Promo: Einstein

If you can’t explain it to a six year old, you don’t understand it yourself

Albert Einstein

I am quite sure that this quote was misattributed to Albert Einstein. However, it seems that you cannot write anything without quoting him, it would be like you don’t know what you are talking about and it would lack authority. This is the main reason why I have used the Einstein wild card; now you have to trust everything I say.

If we want to understand how to apply Domain-Driven Design perhaps it makes sense to firstly understand what a domain is. An analogy would be to try to learn to dance without knowing what dancing is.

I remember when I was a child and there was a concept you didn’t know the first thing to do was to check the dictionary; shall we?

Definition of Domain from the Cambridge Dictionary: an area of interest or an area over which a person has control. Source.

That is really good and simple definition, well I wouldn’t expect less from that source. However, this is quite a wide definition, let’s reduce the scope.

Wikipedia has a more specific scope, Domain from the point of view of Software Engineering, which is more or less what we do.

A domain is a field of study that defines a set of common requirements, terminology, and functionality for any software program constructed to solve a problem in the area of computer programming, known as domain engineering. The word domain is also taken as a synonym of application domain. It is also seen as a sphere of knowledge. Source.

Cool! I guess that with these two definition we should be able to create our own definition. Here is my attempt. The domain is the reason for your software; it is the problem that your software must solve.

No domain = no reason for your software

So it seems quite obvious that to build software we need to understand the domain. While a good understanding of the domain will not guarantee good software, you can be certain that a misunderstanding of it will result in bad software.

All right! We know what the domain is so important. In fact, the domain should drive the whole design, not the technologies, frameworks, databases or user interfaces; just the domain.

Let’s use an example, as this always helps to assimilate a concept. If I want to build software for a school I should know how a school works… and if I want to build software for a pharmaceutical company I should know a lot about pharmacology; however, I am just a developer who knows about writing sentences that a computer executes, so how am I supposed to learn all these things? The good news is that you don’t have to be an expert in all of these subjects, there are domain experts for that, the people who work in those industries, for instance the teachers, head teachers, doctors, scientist, and so on. The bad news it that you are going to have to speak to them and translate their requirements into code: classes, properties, methods and fields for example.

Communication is quite an important concept in DDD.

It fact, communication and the use of language is so important than it has its own chapter in Evans’ book, we will come to that later.

Now I want to write about what we should do in order to create software for a specific domain. Basically, what we want to do, as we mentioned before, is to solve a problem. The best way to solve a problem is bringing together all the information related with the problem itself. However, some domains are so complex and the volume of information related to them is something that in most cases we cannot put together. This is why we need models.

Blimey! Another concept! Cambridge dictionary please!!!

Model (Representation): something that represents another thing, either as a physical object that is usually smaller than the real object, or as a simple description that can be used in calculations. Source.

Again, that is a good one. Let’s see what Eric Evans says:

A model is a selectively simplified and consciously structured form of knowledge. An appropriate model makes sense of information and focuses it on a problem.

Eric Evans

Good old Eric, I love his knowledge about language, but sometimes you have to read a sentence a few times to understand it, quite unusual in technical books.

So, in order to solve a problem we can use a model of the domain (a simplified and conscious selection of knowledge that represents the domain).

What makes a model a good model?

  • A good model cannot be disconnected from an implementation. We need a link between our model and the software implementation. We can obtain a lot of knowledge when we analyse a problem, but we cannot let this knowledge vanish when the coding begins. If we maintain this link, we will save a lot of time during maintenance of our solution.
  • A good model can be used by all team members as a language. This can only happen if is connected to the implementation. Developers can talk with domain experts without the need of a translator.

Communication again! I promise we will come back to that.

  • A good model is distilled knowledge. We have selected what the team think is important from the domain in order to solve the problem and discarded the rest.

 

Summary

Our software has to solve a problem of an area of interest (domain) a model can help us to understand and represent this area of interest;  a good model links design and implementation; the members of a team use the model as a language to talk about the area of interest.
Tags: DDD Domain


About The Author

Jordi Ruiz

I’m extremely passionate about knowledge; wherever I go, you will always find a book inside my trusty rucksack - it could be a technical book, a novel, essays; anything that broadens my mind and understanding.

Post a Comment

Note: Your email address will not be published.
Note: You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Subscribe

Logo

A software company with a simple goal: write good software to help our clients solve their domain problems.

We are people who are passionate and pragmatic with the job that we do.

Our Contacts

Amelia House
Crescent Road
Worthing
West Sussex
BN11 1QR
United Kingdom
Email: info@comment-it.co.uk