Looking through the articles on software design, I constantly met a cloud of unprecedented cuts and casually mentioned development practices.

• TDD - well, everyone knows that, first we write tests, and then the rest of the code.
• BDD is something familiar, sort of like, also tests, but special ones.
• TDD - again? So, stop, here we are not talking about tests at all. But why is it called the same?
• DDD - bound contexts, ubiquitous language, domain ...
• FDD - how much can you?
• MDD - Seriously, based on diagrams?
• PDD - ...

Development approaches are divided by complexity, scope and purpose.
I think it is time to figure out why they are needed, why there are so many of them, and how they can be useful to us.

We will start to get acquainted with them from the simplest to the rather complex, we consider examples of use and the pros and cons of each of them.

TDD - Test Driven Development

TDD is a software development methodology that is based on the repetition of short development cycles: a test is initially written covering the desired change, then a program code is written that implements the desired system behavior and allows the written test to pass. Then refactoring of the written code is carried out with constant verification of passing tests.

It sounds simple and clear. Many people are familiar with this approach to development, and even Uncle Bob itself actively promotes it.

TDD is considered a form of proper application building method. Test-driven design philosophy is that your tests are a specification of how your program should behave. If you view your test suite as a mandatory part of the build process, if your tests fail, the program does not build because it is incorrect. Of course, the limitation is that the correctness of your program is defined only as the completeness of your tests. However, research has shown that development based on testing can lead to a 40–80% reduction in errors in production.

When you start using TDD, you may feel that you are working more slowly than usual. This happens because you will work outside the “comfort zone”, and this is quite normal.

Once you feel that writing tests has become a simple and natural part of the workflow, that you no longer need to think about using TDD while working on a project, you realize that TDD has come into your work.

This methodology allows you to create an application that is suitable for automatic testing and a very good code coverage of tests, since the TOR is translated into the language of automatic tests, that is, everything that the program should do is checked. Also, TDD often simplifies software implementation: implementation redundancy is eliminated - if a component passes the test, then it is considered ready.

The architecture of software products developed in this way is usually better (in applications that are suitable for automated testing, responsibility is usually very well distributed among the components, and the complex procedures performed are decomposed into many simple ones). The stability of the application developed through testing is higher due to the fact that all the main functionality of the program is covered by tests and their performance is constantly checked. Accompanying projects where everything or almost everything is tested is very high - developers may not be afraid to make changes to the code, if something goes wrong, then the results of the automatic testing will be reported.

You can learn more about TDD principles by reading Kent Beck’s book "Extreme Programming. Development Through Testing."

TDD - Type Driven Development

Type Driven Development is abbreviated as well as development through testing, so they usually write the full name.

When developing based on types, your data types and type signatures are program specifications. Types also serve as a form of documentation, which is guaranteed to be updated.

Types are small control points, thanks to which we get a lot of mini-tests for our entire application. Moreover, the costs of creating types are minimal and they are not required to be updated, since they are part of the code base.

Type development is another correct method for building an application. As with testing-based development, type-based development can increase your confidence in the code and save you time when making changes to a large code base.

Of the minuses only increasing complexity in languages ​​with dynamic typing. For example, for JavaScript this approach is harder to apply than for TypeScript.

On Habré there is a wonderful article about typing.

BDD - Behavior Driven Development

Because of some methodological similarities, TDD (Test Driven Development) and BDD (Behavior Driven Development) are often confused even by professionals. What is the difference? The concepts of both approaches are similar, first the tests run and only then the development begins, but their purpose is completely different. TDD is more about programming and testing at the level of technical implementation of the product, when the tests are created by the developers themselves. BDD suggests a tester or analyst of user-language scenarios in natural language — in the language of business, so to speak.

BDD - behavior-driven development is a development based on behavior description. A certain person (or people) writes descriptions of the form "I like the user when I pressed the start button, then the menu was shown as in the picture" (there are specially selected keywords). Programmers have long written special tools that translate such descriptions into tests (sometimes completely transparent to the programmer). And then the classic development with tests.

If you write down the names of tests in the form of sentences and use the business domain vocabulary when writing method names, the created documentation becomes clear to customers, analysts and testers.

Script texts are recorded in a specific form.

Having (approx. Given - given) some context,

When (approx. When) an event occurs,

Then (approx. Then) check the result.

Something like this might turn out:

Or another example in Russian:

+ Scenario 1: There is money in the account +
')
Having an account with money

And a valid card

And ATM cash

When a customer requests cash

Then make sure that the account was written off.

And make sure that cash is issued

And make sure the card is returned.

The BDD approach together with engineering practitioners allowed us to abandon legacy documentation containing irrelevant information, and receive new documentation on the fly, store it with the project, which brought analysts and testers closer to the code.

BDD is rather a process whose goal is to reduce the cost of implementing new features. Even at the start of development, we get important artifacts. For example, understandable to support the documentation. This documentation enables all interested parties to form their own ideas about the product and user behavior scenarios, which should be implemented during development iterations. With the BDD approach, we also reduce the threshold for entry into the project of new participants.

What is the advantage of BDD?

• Tests readable for non-programmers.
• They are easy to change. They are often written in almost pure English.
• They may be written by the product owner or other interested persons.
• The test results are more humane.
• Tests are independent of the target programming language. Migrating to another language is greatly simplified.

Minuses:

But this approach has its drawbacks - it is long and expensive. BDD is inconvenient at least in that it requires the involvement of testing specialists already at the stage of elaboration of requirements, and this extends the development cycle.

The way out of this situation may be the choice of a suitable BDD framework and properly aligned development processes.

Read more about BDD here .

Many have long understood that testing is a kind of panacea for all diseases, but is it really? Of course, thoroughly tested code works more stable and predictable, but tests do not save us from problems and errors at the design and task setting stage. The following design approaches can help you with this.

DDD - Domain Driven Design

Subject-oriented design is not a specific technology or methodology. DDD is a set of rules that allow you to make the right design decisions. This approach can significantly speed up the process of designing software in an unfamiliar subject area.

Domain -oriented design (less commonly problem-oriented, English Domain-driven design, DDD) is a set of principles and schemes aimed at creating optimal systems of objects. The development process is reduced to the creation of software abstractions, which are called domain models. These models include business logic that establishes a link between the actual conditions of the product's field of application and the code.

The DDD approach is particularly useful in situations where the developer is not an expert in the field of the product being developed. For example: a programmer cannot know all areas in which software is required to be created, but with the help of a correct structure representation, using a domain-oriented approach, he can easily design an application based on key points and knowledge of the work area.

In this article I try to convey the essence of each approach to software development, but I can write more than one article about DDD and cover all the nuances in several paragraphs. Therefore, when explaining, I will provide explanatory links to the most worthy sources.

The main goal of Domain-Driven Design is to combat the complexity of business processes, their automation and implementation in code. “Domain” is translated as “subject area”, and it is precisely the subject area that pushes development and design within the framework of this approach.

The key concept in DDD is “ubiquitous language”. Ubiquitous language promotes transparent communication between project participants. He is not one in the sense that he is one for all occasions. Just the opposite. All participants communicate on it, the whole discussion takes place in terms of a single language, and all artifacts should be maximally stated in terms of a single language, that is, starting from the TK, and ending with the code.

The next concept is "domain model". This model is a dictionary of terms from the ubiquitous language. Both the domain model and the ubiquitous language are limited by the context, which in the Domain-Driven Design is called the bounded context. It limits the domain model so that all concepts within it are unambiguous, and everyone understands what is being said.

Example: take the entity “person” and put it in the context of “public speaking”. In this context, according to DDD, he becomes a speaker or speaker. And in the context of "family" - a husband or brother.

Now about the code. It is important that your code reads like a book, is simple and understandable to everyone who speaks the same project language. What I mean?

If in the project language you use the expression "product was added", then the following option is not in DDD:

var product = new Product ('apple')

product.save ()

Why? The code says that we created the product in a strange way and saved it. How to add the product? Need to add it . Here is the DDD code:

Product :: add ('apple');

Architecture:

From the point of view of Domain-Driven Design, it makes absolutely no matter what architecture you choose. Domain-Driven Design is not about that, Domain-Driven Design is about language and communication.

But DDD is almost impossible without the pure architecture of the project, since when adding new functionality or changing the old one, you should try to preserve the flexibility and transparency of the code base. Pro ports, adapters and onion architecture can be found in an excellent article . The picture above is just from it.

There are also articles about DDD that I strongly advise to read carefully - here and here .

What it gives us in the end:

• almost all team members can read the project code;
• task setting becomes more explicit;
• business logic bugs become easier to search;
• QA is much easier for specialists to view the code and find logical errors and bugs.

Minuses:

• highly skilled developers are required, especially at the start of the project;
• not all customers are willing to go for such costs, DDD needs to be learned by all participants in the development process.

FDD - Features Driven Development

FDD - This methodology (briefly referred to as FDD) was developed by Jeff De Luca and a recognized object-oriented technology guru Peter Coad. FDD is an attempt to combine the most recognized techniques in the software development industry, taking as a basis for the customer-important functionality (features) of the software being developed. The main goal of this methodology is to develop real, working software systematically, in the set time frame.

Like the rest of the adaptive methodology, it focuses on short iterations, each of which serves to work out a specific part of the functionality of the system. According to FDD, one iteration lasts two weeks. FDD has five processes. The first three of them relate to the beginning of the project:

• development of a general model;
• compiling a list of required system properties;
• planning work on each property;
• design of each property;
• constructing each property.

The last two steps must be done during each iteration. In addition, each process is divided into tasks and has verification criteria.

Let's take a closer look at each item.

Development of a general model.

Development begins with an analysis of the breadth of the existing range of tasks and the context of the system. Further, for each simulated area is a more detailed analysis. Preliminary descriptions are compiled in small groups and submitted for further discussion and peer review. After one of the proposed models or their combination becomes a model for a specific area. The models of each task pane are combined into a common final model, which may change during the course of work.

List of functions

The information collected when building a general model is used to compile a list of functions. Functions are combined into so-called "areas" (English domain), and they, in turn, are divided into sub-areas (English subject areas) according to their functional characteristics.

Each subarea corresponds to a specific business process, and its steps become a list of functions (properties). Functions are presented in the form of "action - result - object", for example, "check user password". The development of each function should take no more than 2 weeks, otherwise the task must be decomposed into smaller iterations. The list of properties in FDD is the same as the product backlog in SCRUM.

Plan for properties (functions)

Next comes the stage of distribution of functions among leading programmers or by teams.

Function design

For each property, a design package is created. The lead programmer selects a small group of properties for development within two weeks. After that, detailed sequence diagrams are left for each property, specifying the overall model. Further "stubs" of classes and methods are written. At this point, we need to focus on the design of the software product.

Function implementation

We write the code, we remove stubs, we test.

After the property has been tested and put into the product, we take the following property in priority, we repeat the design / implementation cycle.

Total, as a result, we get:

• system property documentation;
• careful design;
• easier to evaluate small tasks;
• tests are focused on business problems;
• elaborated product creation process;
• Short iterative development cycles allow you to quickly increase functionality and reduce the number of errors.

Minuses:

• FDD is more suitable for large projects. Small development teams will not be able to feel the full benefits of this approach;
• significant costs of implementation and training.

MDD - Model Driven Development

Recently, a lot of attention has been given in publications to the theme of architecture and development based on MDA (Model Driven Architecture) and MDD (Model Driven Development) models. Without going into details, select only the key points.

Model-Driven Development (model-driven development) is the style of software development when models become the main development artifacts from which code and other artifacts are generated.

To put it simply, the whole essence of the development comes down to building the necessary diagrams, from which we subsequently generate the working code of the project.

The main goal of MDD is to minimize the costs associated with binding to specific system platforms and software infrastructures. After all, the main business logic is contained in diagrams and does not constrain us within the framework of the choice of programming language and development tools.

Let's digress a bit and remember the compiler. It converts a high-level programming language to an equivalent machine-language implementation. The model in this case is a program written in a high-level language that hides irrelevant details about its implementation. In MDD, our diagrams are another level of abstraction that does not allow us to get bogged down in the details of development, but look at the big picture.

The diagrams act as original “drawings” from which various automated and semi-automated processes extract programs and corresponding models. Moreover, automatic code generation varies from extracting a simple skeleton of an application to obtaining the final code base (which is comparable to traditional compilation).

The idea of ​​MDD is not new - it has been used with varying success before. The reason for the increased attention to them now is that automation lends itself to significantly more processes than before. This development is reflected in the emergence of MDD-standards, which leads to the unification of relevant funds. One of these standards is the revised version of Unified Modeling Language - UML 2.0.

According to the Object Management Group (OMG) standards, creating an application consists of the following steps:

• First, a domain model of the projected application is developed that is completely independent of the implementing technology;
• then it is transformed by a special tool into a platform-dependent model;
• Finally, it is translated into source code in the appropriate programming language.

A classic example of MDD, which has been used for a long time, is database modeling. Based on a single conceptual data model, you can maintain multiple physical models associated with it for different DBMSs.

What advantages we get:

• speeding up the launch of a minimum viable product (Minimum Viable Product) to the market;
• time is reduced by: generating an application framework, class models, databases;
• constantly updated documentation;
• for the participants of the project diagrams are much clearer than the code.

Minuses:

• MMD implementation will require the use of special software solutions such as Rational Software Architect, Simulink or Sirius;
• programmers are required to have impressive knowledge of designing diagrams;
• significant financial costs for the integration of this methodology.

PDD - Panic Driven Development

If you have tried agile development methodologies, then you probably also tried PDD. Let's take a closer look at what the principles of this methodology are.

New tasks take precedence over old ones.

Whenever a new problem appears in the middle of a sprint, it takes precedence over any scheduled work. New is always better and has a higher priority. Strange, why it did not become one of the principles of agile development? Focusing on providing value for the client requires that the team take care of new features and put off previously defined work.

Write as much code as you need to solve the problem.

Developers write code for life. Errors can only be corrected by code. Discussion of design and UX can only slow down development. But we do not want to lose precious time? First write the solution, then check your guess for the correction. If the fix works, the problem is resolved.

Tests should be written at the end.

After the patch is implemented, tests can be scheduled as a task to be done in the future. Tests are useful, but not prioritized. You can take care of them later. Manual testing should be sufficient to prove the operability of the implemented solution.

Trust your instinct.

Programming is an art. Art has an internal instinctive component. Trust your intuition. Write the code. Deploy it. Only brave smiles luck.

The process is flexible.

Any process created to develop, test, and release software is simply a set of agreements and rules that are not set in stone. Critical fixes require different approaches. It is expected that you will bend the process to complete the task on time if the business requires it.

This is a manager driven process.

As part of the same team, managers have the right to express their opinions on development issues. Refactoring or best practices can and should be reversed by business needs. Engineers can give their opinion, but they must ultimately accept any needs that come from above.

Advantages of the approach:

• high speed development;
• cheap;
• Customers are happy to finally find intelligent developers.

Minuses:

• All advantages will be broken about technical debt and complexity of the project .

PDD is a kind of development anti-pattern, which, unfortunately, we all practice from time to time.

Conclusion

The world of agile development is multifaceted. We met only a small part of it, reviewed a sufficient number of software development practices, learned about their advantages and disadvantages.

I hope many of you have learned something new about the Driven Development practices, and now, having come face to face with the abbreviations DDD, BDD, MDD you will not be confused, and you may even want to try them in practice.