Domain Driven Design with Web API revisited Part 1: introduction

Introduction

Domain driven design (DDD) has been around since 2003 when Eric Evans published his groundbreaking book on the subject. It is quite a large and complex topic with a steep learning curve. Chances are that it will take years of training and hands-on experience before you can get fluent with all its parts. Also, it takes truly large projects, like SAP with all its modules, to utilise all ideas presented by DDD. I have to admit that I’ve only come to work with a subset of DDD, such as aggregate roots, value objects, entities, repositories etc., and haven’t worked with e.g. an anti-corruption layer. That’s fine, applying DDD to a software project doesn’t necessitate using every single field from DDD. You could then easily bloat your project unnecessarily.

There’s a series of posts dedicated to DDD on this blog starting here. It goes through the basics of DDD with a simple domain. If you are entirely new to DDD then you’re advised to read at least the first 2-3 posts so that you get familiar with the most important concepts.

Be patient with DDD if you’re tackling it for the first time. It’s a good idea to process it in chunks. The following diagram only shows a small subset of DDD concepts:

However, if you try to absorb the full picture…

…then you may be daunted by the prospect of having to learn all that at once.

The good news is that you don’t have to. An analogy is learning a new foreign language or a programming language for that matter. You’ll start by saying things like “Hello, my name if John” before learning about the more complex pieces of the language, such as noun declension or the passive voice.

Chances are that you’ll never use every single detail of DDD in practice. As stated above I have a lot to learn myself, which is a motivation to put all of it down in writing in a blog like this. However, you can easily take advantage of some of the most central ideas in DDD and build on those eventually.

By the way, Eric Evans’ book has got some followers:

• Patterns, Principles and Practices of Domain-Driven Design
• Implementing Domain-Driven Design

They are great resources and are definitely worth reading if you want to deepen your knowledge of DDD beyond what a blog post can provide.

Scope

The scope of this series is to revisit DDD and reinforce what we learned before with a different problem domain. I will take an example from my work: load testing where customer can schedule load tests in which they can get a better insight into how much of a load their web sites can take. We’ll go through this in more detail in the next post.

You can think of the original series as a detailed introduction to the key concepts of DDD such as entities, value objects, aggregate roots or repositories. It’s admittedly hard to apply any DDD to a project without knowing about those ideas first. The primary goal of this new series is to build on what we learned there with a different problem domain – i.e. the domain that the software is trying to model and solve – and also introduce a couple of new concepts so that we widen our knowledge.

I won’t necessarily regurgitate every single detail presented in the original series, that would be futile. I will either copy the relevant bits and pieces or provide a link to a more detailed explanation. We’ll eventually also introduce some new concepts like the bounded context or domain events that were not taken up before.

This series will be organised into a number of sub-series that I will publish probably throughout the rest of the year. The sub-series will be intercepted by other topics as is usual for this blog. As this is a large topic we’ll start off with a skeleton with not too much behaviour and gradually add new bits and pieces to it later on. Brace yourselves for a long series. Even this skeleton project will probably span 15 or more parts.

Technology

DDD is definitely NOT about technology. DDD is all about the domain. If there’s only one thing you’ll take away from this series then it should be the following – quoted from Eric Evans book about the domain layer in a project:

“This layer is the heart of business software.”

We’ll come back to this point in a bit.

However, in a real project you’ll have to consider technology as well:

• Repository: how do we persist our objects? In MS SQL, Oracle, MySql or MongoDb? Shall we use some kind of ORM?
• UI: do we need a public web page? Do we have to consider mobile platforms in CSS? Do we need a public API as well?
• Infrastructure: how do we authenticate our users? How do we send emails?

Those are all important questions but not the most important ones in DDD.

The domain

Instead, the single most important aspect of DDD is the domain, also called the model. It describes the business that the software is trying to implement. What products do we sell? What rules do our products follow? How do they behave if we apply some changes to them? The domain is the central ingredient of a DDD-based project. It should be an independent component – layer – in your project that doesn’t have any dependency on the other layers – with the possible exception of the common infrastructure layer where we store the common ingredients of our projects.

If you read the first post of the original series you’ll see an example of how NOT to layer your project. There’s a high risk that the repository layer will become the centre of attention as the services and the UI will use its public methods directly. You can even have a project where the UI directly queries the database through the object context of Entity Framework. This is the so-called Smart UI antipattern which is still prevalent even in large modern software projects.

Admittedly it is often difficult not to concentrate on the technology when a new project starts. After all engineers are engineers because they are interested in technology, right? That’s also true of software engineers. It’s great to discuss and test new technology such as web sockets or Big Data messaging services as they arise and see how they can be implemented in our projects.

Large projects, that otherwise would merit – and necessitate – the usage of DDD are often bogged down in technology-related discussions and the domain layer doesn’t get the attention it deserves. It will end up being a collection of classes with public getters and setters and no domain logic at all. That is NOT Domain Driven Design for sure.

Instead, it all should be the way around. The developers should first and foremost get the domain sorted out and put a lot of effort into it as it evolves and the project progresses.

When to go for DDD?

Having said all that you may think that DDD is there for every single project. No, it’s not. DDD should primarily be used in projects with a complex enough domain. What is “complex enough” is not always easy to determine. A rule of thumb can be the number of rules and the extent of logic applied to the domains. If you see that the problem domain only requires CRUD operations with very little behaviour then DDD could be overkill. An example could be an administrative web page where users can add, update, view and delete customers. In this case it may be enough to build simple classes with properties like Name, Address etc. and implement a simple CRUD-based application.

On the other hand if you find that there is a significant set of rules and behaviour in your domain than DDD can be the way to go. SAP, mentioned above, is probably an excellent example with its independent modules. E.g. the logistics module will only allow the user to order new material if a number of conditions apply:

• Is there not enough on stock at this moment?
• Is the user authorised to order this material?
• Is this material available at the selected supplier?

…and probably much more, I’m not too well versed with SAP in reality. Also, I don’t know whether SAP is implemented with DDD but if the original developers started to build the project today I would definitely recommend it.

I cannot tell just by looking at these public web pages whether or not they use any elements of DDD in their solution but I can imagine that their problem domain is large and complex enough so that DDD is justified:

• The betting site Betsson
• Volvo
• Amazon

Note that we’re talking about complexity in the domain which is not the same as technical complexity. A technologically complex application can still have a simple problem domain which may not justify DDD.

Advantages and disadvantages

The main benefit of DDD is that it helps you manage the complexity of the domain through well defined boundaries, common patterns and by breaking down large and rigid software components into small and flexible ones. You’ll also find a DDD project easier to extend later on when the customer wants to add a new feature or modify an existing one.

I think the most serious disadvantage of DDD is its steep learning curve, especially if a project has a tight deadline. You might be able to deliver the first version of a product without DDD on time and that may be all that the management cares about. If you are part of an organisation where you’re the only one with some knowledge of DDD then be prepared for a hard time trying to get benefits of DDD across. You can count with lots of questions like these:

• Why do we need domain classes?
• Can we not let Entity Framework generate the required classes from the database and get on with the project?
• Why is it so important to have an independent domain layer?
• We’ve always been working the traditional way, what’s wrong with that? Why change it???

This is especially so if your management is not aware of software design principles at all and consider software development as just a process of producing code. In that case you have to start with things like what’s an interface, what are design patterns etc. You may need to introduce DDD on your own without informing the rest of the team but “politically” that may be risky.

OK, that’s enough for now. We’ll introduce the problem domain of the demo in the next post.

View the list of posts on Architecture and Patterns here.