What really is DDD and when does it apply?

Question

When I first studied MVC in the book I talked a lot about DDD (Domain-Driven Design). From what I understood at the time, the idea of the DDD was simply to program software with a focus on developing the domain layer.

After that, reading about the process of analysis and design in object orientation I had the impression that whenever we program an object-oriented software we place this emphasis on the domain layer, starting with it and using the requirements to assemble it properly.

This makes it seem that the DDD basically preaches the same thing as the analysis and design process in object orientation. So what really is the DDD and when does it actually apply? What are the advantages of using DDD in a project?

I know there’s a book called Domain-Driven Design: Tackling Complexity in the Heart of Software, but for being a very extensive book I could never stop to read it. There is some more brief reference on the subject?

Answer 1

Domain-Driven Design or Domain Oriented Design is an object-oriented software modeling standard that seeks to reinforce OO-related concepts and best practices.

This comes in contrast to the common use of Data-Driven Design or Data-Driven Project, which most developers use without even being aware of it.

Data-Driven Development

I have heard several times that data is the most important thing in a company, so modeling should always start thinking about the database.

It is nothing unusual for developers . Net, Java and C++ start a system establishing the guys that they will use and the relationship between them. These types are usually "dumb" objects, with getters and setters, representing nothing more, nothing less, than a database table.

The problem with this approach is that it does not make good use of the Object Orientation features. Many think that getters and setters are the pinnacle of encapsulation, but in practice these methods allow the user to recover and change all attributes. There’s no gain, except a lot of unnecessary code.

Anyway, many people think they are using OO, but the classes could easily be replaced by records or structures, according to the language used.

Domain-Driven Development

The initial idea of the DDD is to go back to a purer OO modeling, so to speak. We should forget how data is persisted and worry about how to better represent business needs in classes and behaviors (methods).

This means that in ddd one Cliente may not have a Setter for their common attributes, but may have methods with business logic that in this business domain belong to the customer, such as void associarNovoCartao(Cartao) or Conta recuperarInformacoesConta().

In short, the modeled classes and their methods should represent the business of the company, using even the same nomenclature. The persistence of the data is placed in the background, being only a complementary layer.

When not using DDD

Sometimes all it takes is a CRUD

DDD is not a solution for everything. Most systems have a large part composed of basic registers (CRUD) and it would not be appropriate to use DDD for this.

The DDD should help in the modeling of the most important and most central classes of the system of form and decrease the complexity and help in the maintenance of them, after all this is the objective of the principles of orientation to objects.

Sharing data with other systems

Integration routines that receive or make data available to other systems should not be "intelligent".

Many developers end up modeling their business classes trying to solve the internal issues of the system and at the same time thinking about how these classes will be exposed to other systems.

Standards as DTO (Data Transfer Object) who use "dumb" objects are more suitable for this.

Final considerations

DDD does not attempt to solve all problems of all layers of a system.

Its focus is on modeling the core business entities using the appropriate language of that domain to facilitate maintenance, extension and understanding.

Particularly, I would not follow the pattern to the letter, because there are numerous patterns and variations of OO modeling. Study the principles behind these patterns, as they are usually similar and see what works best for each project.

References

1. DDD - Introduction to Domain Driven Design
2. Coding for Domain-Driven Design: Tips for Data-Focused Devs
3. Domain Driven Design Quickly (free e-book)

---

^{Note: I wrote terms like Domain-driven hyphenated, because when two or more words form a compound adjective in English they should usually be "linked". In this case, Domain-driven is an adjective of design. (Reference)}

Answer 2

What is DDD?

Domain-Driven Design (DDD) is a software development approach where design is domain-driven, i.e., the area of knowledge to which the software applies.

Another way of saying is: in DDD, the solution design is guided by business rules.

This does not mean that other aspects of software such as persistence or data modeling are ignored. Quite the contrary - the DDD offers solutions that take into account all layers of the system.

Why DDD?

The main objective of the DDD is to keep under control the complexity inherent in software that meets complex needs.

He starts from the premise that software development is a constant struggle against complexity. When not actively controlled, complexity increases the cost of development, evolution and maintenance, erodes quality, degrades performance, opens loopholes for gurus or heroes to establish themselves.

How to make DDD?

The goal is pursued by applying a set of concepts, Patterns design, and even behaviors (of people) in the development of software. See some (I repeat, some) examples:

a) Concepts

• Model: Description of some aspects of the domain. In practice, it is the modeling of business objects.

• Bounded Context: A single model do not need to solve all the problems of a complex system. A system can have multiple models and the limits of a model must be well defined. Each model evolves without being distracted by others.

• Ubiquitous Language: A common language, able to describe the Domain, the model, the context, and that should be practiced by all - developers, business experts, and by the code itself. That is to say, the code speaks the language of business. A change in a business term will imply a change in the code. It’s hard to choose the most important concept of DDD, but if I had to, I’d choose the Ubiquitous Language.

b) Design Patterns

• Entities: Objects that possess identity and that are distinguished by this identity and not only by their characteristics. Obviously, we are talking about identity for the business. In addition to attributes, Entities may also have behaviors.

• Aggregates: Set of entities aggregated by a Entity root. Some entities do not in themselves have a global meaning in the domain; rather, they only make sense when preceded by a Entity "father". This Entity father is then the root of a Aggregate and the entities daughters can only be accessed through this Entity father.

• Services: Business operations that are not the responsibility of any Entity in particular.

Unfortunately, these and others are common Patterns design of the DDD to be confused with other purely technical names on account of similar names.

c) Behaviour

• Continuous Integration: Developed by a team, the model may end up evolving in opposite directions, be fragmented or broken. It is necessary to integrate the code continuously, with execution of automated tests.

• Hands-on Modelers: Those who model also know how to code and actually do so, even less than other people on the team (except for the business expert, who helps to model but not program). In addition, everyone who programs understands the model, participate in discussions about it and are in constant contact with the business expert.

• Refactoring: Not only to solve technical aspects of code without affecting behavior, but also to improve the behavior itself model.

When DDD is used?

I have described here a few aspects of the DDD because you can’t teach how to do it with little text and you can only learn it with a lot of practice. DDD is complex, difficult, the learning curve is long.

So, DDD is a waste on trivial or more data-driven domains than complex business rules.

The projects that benefit most from Ddds are those of very complex business rules. In addition, it is necessary to have favorable conditions such as iterative development capacity and a business specialist available for the development team.

What are the advantages of using DDD?

The advantages come from achieving the goal of the DDD. The essence of a software developed using DDD is you delegate the correction of a bug or even the development of a new resource to a new person on the team after having talked to it using only pencil and paper, without even turning on the computer - I mean, you don’t talk about the code, you talk about the business.

DDD and Object Orientation Considerations

"This makes it seem that the DDD basically preaches the same thing as the analysis and design process in object orientation."

In this answer I hope to have made it clear that the DDD is different object orientation, as DDD delivers concepts and Patterns design that you do not need to use to make a code perfectly oriented to objects.

Is there any more brief reference on the subject?

I don’t know any good summary reference. All the summaries I meet have several misconceptions. There are good discussions only on specific topics.

Eric Evans himself (author of DDD birth certificate book), published a summary of his book, but it is not so summarized (62 pages) and in my view serves as reference only to those who have read the book or already know DDD by experience.

I don’t mean that you first need to read and assimilate the entire book before you try DDD. Practice can rather come before deep knowledge. Many developers think they are doing DDD after reading a short list of their Patterns design - is a good start, but those who stop there never get to know the real benefits of DDD.

Completion

For this answer there is no lesser conclusion than the text itself :-)

Answer 3

What I read about and also participating in a project was:

The main objective is to guide your project to the business, that is, your code has to tell you exactly how the business is applied in your company.

For example your company has the Financial area, so your code should have a class calling for Financeiro and as methods Emitir(), Faturar() etc. Of course, DDD is much more than that. I also know that in the beginning it is difficult to apply it due to couplings and even understanding of the business.

A link in English that can help you understand better would be: http://www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-design/

Answer 4

One of the big problems of adopting DDD, from my point of view, is that you need a solid knowledge of the language technology that you use:

when we take to study the DDD, the authors experts even try to give a way to teach focused on the language they use.

A good example I can give you, with my experience with DDD and . NET is that, in order for you to create a software using DDD, you need to have enough perseverance in studying many patterns of language projects together, which makes it difficult as most of the tutorials and books we find on the internet and even courses, explain everything separately.

You to build a software using the DDD standard, of course, there are some basic things you should do to make it truly a DDD, but, a solid and very well built software at least on the platform. net I can tell you use at least:

DDD, TDD(Test Driven Development) for each layer, BDD(Behavior Driven Development), Dependency Injection, Entityframework(can be others), code-first, structureMapper, Specifications, Domainevent, Validation, Factories...

finally there is a number of design patterns, and frameworks that we must have solid knowledge... and not simply understand the DDD just by the book...

and have a strong programming logic so that we can take full advantage of the technology that the language we choose can offer...