Introduction

I would like to talk about the experience of applying DDD practices to an existing Ruby on Rails project. Initially, we had a monolith, which was written 10 years. The main difficulty of the project was rather complex processes and high connectivity. We managed not only to decompose the application into separate services, but also to significantly increase the readability of the code, to make the described processes transparent.

Problem solving within the framework of the system became predictable, we stopped working with the black box, and in the end the system itself began to prompt us with solutions.

To facilitate both perception and writing, a story about the approaches used will be presented in the form of a series of articles. This approach is not a "silver bullet", so I would like to highlight first of all the segment of projects that this solution can approach. Next, I will talk in more detail about the DDD methodology and microservice implementation of this pattern, sign for possible combinations of the applied patterns with regard to their implementation, and ultimately give an example of a specific implementation of one small service.

Thesaurus

Thesaurus is a glossary of terms used to describe a specific subject area.

All definitions that will be introduced below are correct, in this article. You can apply them to your subject area if they describe it well enough.

Problem solved in the framework of this approach

The following approach has a fairly narrow specialization, and, above all, is aimed at solving a specific problem. However, this does not exclude the possible interest of specialists from related fields. So, we have a task:

You need to rewrite and maintain a project with complex business logic, written in Ruby on Rails, with enough resources available.

Let's write out this task in more detail.

Why is it necessary to rewrite the project?

I think every developer can answer this question. It is more difficult to answer in such a way that this answer satisfies the demands of your business.

We use the definition of Business , since it is generally accepted, although we will invest in this term a broader concept - an enterprise (something undertaken by a group of people), an occupation (busy).

Business is an effort of a company of people, expressed through an action aimed at obtaining benefits for a wide range of individuals.

For example:

• The company makes a product for consumers or provides a service.
• The laboratory is developing a new drug.
• The school is engaged in learning.
• City Archives provides information to citizens.
• Lera pleases her fans with an excellent figure in the social network.

In the mass case, the business is built around the idea to make a profit through the needs of its customers. In order for recoverable profits to increase, it is necessary to satisfy the actual needs of the client with a large number of quality solutions. This idea is described as the first principle of the Agile manifest, although the idea is not new. The fact that the needs underlie our society was claimed by many philosophers. For example, Plato tried to streamline the needs, create their classification. That he calls the main forms of economic needs: food, clothing, housing. "The challenge of business" is to satisfy needs. And the solutions used should increase the competitiveness of the business.

Competitiveness - The advantage of one business over another.

Agile manifest also gives us a hint that the project's flexibility is enhanced through its technical excellence and design quality.

Consider the cycle of delivery of values ​​on the example of "Typical web-project"

• t ₀ - we had an idea.
• t ₁ we implemented MVP . Here we digress a little:
  
  

  MVP minimum viable product (Minimum product) is a product that has minimal, but sufficient functions to satisfy the first consumers. The main task is to obtain feedback for the formation of hypotheses for further product development.
  
  

This term was popularized by Steve Blank and Eric Ries. MVP is an effective enough tool to try out your business idea and answer the main question, "Fly up - don't fly up?"

• t ₂ - Back to the chart. The idea was successful, we received positive feedback and were able to satisfy a large number of customer needs at a specified time.
• t ₃ - This time satisfaction has come to a lesser degree. We have increased staff.
• t ₄ - We have set even fewer values.
• t ₅ - If we have not started Refactoring, then at this time the business ceases to be competitive.

Why it happens? With the passage of time, our project accumulates a high level of entropy due to its high connectivity. Suppose we have a “Typical Company” consisting of a marketing, analysis, logistics, sales and management department. At the moment, the project is as follows:

I would like to immediately say that connectedness is not always the cause of entropy, but it occurs if a system with a high number of complex business processes is implemented.

Entropy in the code will always occur if the business processes in the company are not formed properly. What can be characteristic of both young companies that are at the beginning of their journey is typical for large companies where it is impossible to systematize everything all at once. This is a natural process and we should not stand in his way, but take it and use it. Let's go back to the first chart and look at it from the other side:

The integral (area under the line) will be the money earned. The real application (Real app) will earn more than the "ideal" (Academin app), at least until the time of the onset of entropy - t ₄ . Sounds good and needs to be done.

But what to do in the future? Repeat refactoring to infinity is not possible. At some point in time, the volume of the code base will reach such a level that it will be difficult to rewrite "everything at once". And sooner or later it is necessary to break the project into separate components:

One approach to implementing complex systems is DDD:

Domain-based design (DDD, Domain-driven design) is an approach to developing software for complex needs satisfaction, by strongly linking the implementation with the main business models that are in constant development.

DDD is a series of practices and definitions that will be described in more detail in the next article. The central pattern of this approach is the Limited context , its essence is that each subject area consists of several sets of models that do not have to communicate with the outside world, as well as models that are shared with other limited contexts in the outside world. Each limited context has a well-defined interface where it decides which models to use in conjunction with other contexts.

This pattern can be implemented through a namespace (namespace), and through microservices. We will use both the one and the other implementation, depending on the level of context relatedness. Which ultimately leads to the creation of a decomposed, segmented application.

The above charts are unlikely to reflect the real picture, but they will allow you to compare different approaches with each other.

Project support

As part of project support, you need to provide a number of things.

• Delivery values : Scrum, Agile, customer service, Continuous delivery.
• Entropy reduction : DDD, Micro-service as one of the ways to separate contexts, documentation.
• Quality code : Design at the domain level, TDD, BDD.
• Product quality : Manual and automated testing, bug tracking, logging.
• Product availability : Duplication systems.
• Product speed : horizontal scaling.
• Retention of the development team : System of motivation, openness, honesty.

As can be seen, a large amount of resources is required to maintain a complex system. First of all, highly qualified personnel. Before using this or that technology, consider whether you have the opportunity to provide its support at the right level.

It should be remembered that the threshold of entry into a complex system is quite high, so it is important to provide staff training. Also, if we want to work without failures, we should not have "irreplaceable" specialists, and therefore it is necessary to ensure the full interchangeability of all roles. If you flew from the 'Continuous Delivery Specialist' team - you need to replace it. If the replacement cannot be ensured, then it is not necessary to introduce a technology stack into "production" without providing sufficient support.

Here we are not talking about specialists of the same level. Let you have a leading DevOps and some developer for whom this topic is interesting (the so-called "multiclass"). For him, as for the "second violin", it is important to provide an understanding of where and how to find the tools to solve the problem. For this, at least a quarter of the total volume of incoming tasks related to the new specialty should be allocated to it. These tasks will be executed slowly, costs will increase, but in the future this will prevent the risk of interruption of the supply of valuables due to personnel shortages.

Such things are described in the requirements of Scrum, I would not want to dwell on them. The only thing I would like to draw your attention to, what you need to be prepared for is the high costs that will be spent on supporting your project. If your business is not ready for this, and you have started using many expensive tools, you will ruin the business.

Briefly

• If you have a task to implement MVP , start with Ruby On Rails.
• If the MVP took off and the idea was justified, make the first refactoring, "facilitate" your models with the help of services, decorators, validate and work with the database from the models into separate concerns. Write tests, documentation.
• If you do not have such a complicated project and you can remove the entropy by optimizing the models - do it.
• If you have a logical, readable project, and you need to improve its performance, while it can be divided, say, by user, then use scaling. But do not try to break the project into services by domains.
• If you have a “tricky” business and you are looking for a tool to go online (why haven’t you done it yet?!), Consider also ready-made “Enterprise solutions”, say, java or .NET. The described practices were born in such solutions and they have a rich ready-made toolkit that will save you money.
• If your project is ruby, you have ruby ​​programmers, the project contains complex business logic, is preparing for a load or is already loaded, and the entropy has increased so much that it is very difficult to rewrite, then you should consider using the DDD approach and Microservices.

---

Next time I would like to consider in more detail the essence of the DDD approach and its microservice implementation.

---

Sources of inspiration:

• https://habr.com/post/351242/
• http://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html
• http://agilemanifesto.org/iso/ru/principles.html
• http://dddcommunity.org/learning-ddd/what_is_ddd/
• https://martinfowler.com/bliki/BoundedContext.html
• Creating microservices, Sam Newman
• The Hitchhiker's Guide to the Galaxy, Douglas Adams