Is it Unviable to use Domain-Driven Design working alone?

Question

I have studied a lot about DDD and I am with this doubt that has been bothering me since I started reading about "Strategic design". I work with programming since 2009 and most of the time I have always worked alone. I’ve developed software with closed scope, a specific client and everything. But at the moment I am working on some projects "software as a service" developed to be sold later, that is, without any specific client waiting for the software for his company.

Logically, to be able to model things correctly I have available domain experts who provide the requirements and everything. The fact is, I don’t have a team. I read that if I work alone I have to forget DDD and find another way to work and it worried me a little, because several problems I’ve seen that without using DDD are extremely complicated.

When I started reading about "Strategic design", about subdomains and bounded contexts it seemed very useful. In fact, several problems I had in previous developments seemed to be much simpler using these ideas. The problem is the fact that reading about it I see a lot of focus on teams: "allocate a team to each bounded context".

This is clearly impossible working alone, but still it doesn’t seem to me that I can’t apply the ideas of "Strategic design".

So what I want to know is the following: taking into account all this and mainly that I am working on projects that have no deadline and no closed scope, is it possible for me to take advantage of the ideas of the Area Code, mainly the "Strategic design"? If so, how can I do that?

Answer 1

I believe that this question does not have an objective answer but I will give my opinion anyway.

More than team size, the choice of application architecture is more related to the size and complexity of the problem/domain/model being implemented and the estimated lifetime of the application.

It is necessary to balance the effort to perform DDD versus the frequency and complexity of application maintenance. Effort will not always be rewarded.

On the other hand, I wouldn’t want to discourage anyone from trying DDD when possible. Whether you like it or not, a very decisive factor will always be the developer’s desire to learn something new that promises to make your long-term life easier.

Answer 2

DDD is not directly linked to team size

DDD is a strategy to deal with domains where there is a wealth of concepts and interactions between them. When one is interested in modeling this complexity, one should consider DDD. Of course, in scenarios like this it may be more natural to have several people involved, but there is no restriction in this sense.

I believe that you have already acquired the "feeling" needed to identify the scenarios for applying DDD, according to the third paragraph of your question. This same paragraph provides crystal-clear guidance on whether or not to use DDD: just like any other strategy, you need to look at the context. DDD is not applicable in all cases, as is any other strategy. We need to develop insight into the right scenario for your employment.

Additionally, as the question suggests, the same application may have parts developed with the support of DDD and others not. And again, there’s no problem with that. It probably won’t employ DDD in a problem that can be solved with a spreadsheet in a few hours, or a script to print files deposited in a directory. On the other hand, it will probably make use if there is interest in modeling and recording concepts such as events relevant to a given domain, as well as operations, business rules in abundance and others. It’s definitely not as clear an explanation as we’d like, but I believe it provides some guidance.

Finally, how many strategies are alive after two decades?

Answer 3

I would recommend using DDD even if you programming alone, unless the project is small, and has no complex business rules. The DDD forces you to understand more about the domain, and this understanding is essential for the production of good software.