Domain-Driven Design: Tutorial for Rookies

In 2004, Eric Evans presented a book called ‘Domain-Driven Design: Tackling Complexity in the Heart of Software’. While this was the first time the concept was introduced to the world, it soon gained a following. Why, you ask? The reason is simple. The idea of any software ever engineered is to help its user solve a problem that is closely related to a particular domain.

However, everyone who ever tried to learn software architecture will tell you the part of the process that causes most issues is the domain itself – and Eric Evans came up with a way to control it. In this domain-driven design tutorial, I will guide you through all the main concepts and ideas of this software development approach.

If you have any previous knowledge or experience in either engineering software or building its architecture, this course will be a breeze. There’s no need to worry if you don’t, too: I have tried my best to make this domain-driven design tutorial beginner-friendly. Truth be told, it’s great for getting to know the topic from scratch: all the lectures are purely theoretical, and no actual coding is involved.

What is the domain, and what challenge does it pose for a developer?

Any good domain-driven design tutorial begins with getting the terminology down. In software engineering, the domain represents a particular field of knowledge or action that the software is related to. For an automated trading robot, the domain will have to do with trading stocks or currency. For a system that’s supposed to help you monitor your health, the domain contains medical knowledge. You get the gist.

However, most software developers get to work with systems they don’t necessarily understand the domain of very well. Without understanding the domain, it’s virtually impossible to help the business reach its goals. Still, it’s also illogical to expect a programmer who did their best to learn software architecture will have extensive knowledge in a great deal of other areas as well. This is precisely why domain-driven design training is so crucial for any IT project team.

Combining technical skills with the expertise of the domain

In this domain-driven design tutorial, I will explain how the dilemma described above can be solved by including subject matter experts in the project teams. Thoughtful collaborating allows us to create software that’s highly functional in both technical and practical sense.

To be able to discuss the business logic and the needs of a particular project, the developers and the experts use what is called the ubiquitous language. In this domain-driven design tutorial, you will learn how to come up with one yourself. In addition to that, you’ll get to know all the main components of this approach, including but not limited to entities, value objects, aggregate roots, factories, and repositories.

In less than two hours, you can get a solid grasp on how to build software that is both a technical masterpiece and achieves the goal of solving domain-related problems. Get your notes ready and tune in now!