As the scenarios we address become more specialized and complex, and large SPA applications become popular, the front-end takes on more responsibilities. It’s easy to iterate and discover that the code doesn’t change. They had to start all over again. At the end of the day, complexity is out of control, and some ideas are needed to guide development.

Background:

Why is iteration getting harder? Here’s why:

  • The problem domain itself is complex

    • Software itself is designed to manage complexity, and the problem domains we now face are complex. To create truly useful software, developers must have a body of knowledge about it

  • The technical model does not match the domain model

    • It is easy to abstract a single class or function to hold generic logic, which is generic only in the technical dimension. Generality in the technical dimensionEasily destroyed by business. Changes or expansions in requirements, the universality of the technical dimension can easily be destroyed. The root cause is what we designedThe technical model 与 The domain modelDon’t match. So every change in requirements, mapping to a change in the technical model can be a huge amount of work. When the business is under great pressure, we can only tell the product manager that it can be done, but we need 2 months. The result is likely to be a compromise on the demand side at the expense of users. The product becomes more and more difficult to use.

  • Loss of knowledge

    • Any project will lose knowledge, and outsourced systems may only return code, but knowledge will not be passed on. They leave jobs, they change jobs, and once for some reason people don’t pass on knowledge orally, knowledge is lost.

These three problems boil down to the fact that we did not clearly describe our business in the front-end code. We are view driven rather than business driven in many cases. A lot of times it’s just about what the page looks like, what requests are made and what data is taken. So everyone has a different depth of understanding of the business concept. The solution to this problem may be to adopt a new development approach of domain-driven design.

What is Domain-driven design?

Domain-driven design is the idea that the domain model drives the design of a system, rather than storing data dictionaries (DB table fields, ESMapper fields, etc.). Domain models are abstractions of business models, and DDD is a way of translating business models into system architecture designs.

Models in DDD

Model and traditional POJO(DTO, DO, DAO) class contrast, are a class with attributes, attributes have Get/Set methods, and DO the transfer object. Model is compared with Service in the business logic layer of traditional MVC three-tier architecture layer, which deals with business Action layer. Models, which carry business attributes and specific behaviors, are the way business is expressed and the core of DDD. Is a class with attributes, attributes have Get/Set methods, and business Action operations are also in the model class (congestion model), which does business logic processing and data transmission objects. The model is divided into Entity, Value Object and Service. This is all server-side jargon. In simple terms, prioritize business concepts over other types of classification of the code base (for example, grouping by file type). This means that you should organize your code around your main business area (the “problem”) and its subareas (the subsegments of the problem). For example, in e-commerce, we have sub-areas like catalog, customer, order, inventory, etc. Although DDD concepts come from object-oriented programming and rely on classes and their relationships, its core concepts can easily be applied to other paradigms.

Front-end application domain model (from:Front-end development – Domain driven design · Wordplay ）

In many cases, the domain model is built by the backend students. How can the front-end students guide the development?

  • Understand the back-end domain model

    • By understanding their modular division, we can borrow directly from their model, which also ensures that the front and back ends have the same understanding of the business model.

  • Build a front-end domain model

  • Separated domain layer

It is important to emphasize that the domain level construction must not be two pages at the same time to send a request, then pull out the request, give a domain name. He must have been built in advance. A layer that is designed before the front-end design begins. We want to take all the page components and business activities within the module out and put them in the appropriate domain module. As long as it is a business activity, there must be a domain module that can fall. If not, the domain model is not properly designed. The goal of driving domain-level separation is not to reuse pages, but to convert that into thinking. The domain layer is not pulled away because it is reused in multiple places. It was pulled away because:

  • The domain layer is stable (pages and modules bound to pages are unstable)

  • The domain layer is decoupled (pages are coupled, data on pages comes from multiple interfaces, multiple domains)

  • The domain layer is extremely complex and deserves to be managed separately (the View layer handles page rendering and page logic control, and is complex enough that the decoupling of the domain layer can lighten the View layer. The view layer is as light as possible is our architect CNFI’s main idea)

  • The domain layer can be reused on a layer by layer basis (your code may discard a technical architecture, convert from VUE to React, or launch a mobile version, in which case the domain layer can be reused directly)

  • For the continuous evolution of the domain model (the purpose of the model is to make people focus, and the benefit of focus is to strengthen the front-end team’s understanding of the business. Only by thinking about the business process can the business move forward)

  • Dominant interface convention

Interface conventions should be led by the front end as far as possible. After all, interfaces are used by the front end, and it is more reasonable for the front end to design interfaces.

  • Pay attention to business implications in development

Name classes, methods, and modules directly to the business core, consistent with the domain model.

  • Real-time synchronization

Make sure that all students in the team are familiar with the model of the system. Especially for new students who need to be familiar with and modify the code, share the domain model of our system before introducing the technical architecture. Different priorities lead to different programming worldviews. This will get new students into the habit of deciding whether or not they fit into existing models before making technical decisions. Constantly thinking about models is what helps our business grow.

Domain-driven design in React?

In general, the SRC directory should contain only assets, Pages, layouts, and app.

  • Less, xxx. TSX, usexxx. ts, and usexxx.spec. ts. It adopts nested structure and hooks to achieve convergence and reuse of related state logic

  • A folder contains all logic in that domain (views, styles, tests, states, interfaces). It is forbidden to place logic outside the folder

  • If it needs to be called by other functions, it is combined with an inversion of control (dependency injection) SOA

Use the hooks to implement DDD in React.

DDD can be said to be the trend of the whole software development architecture design, front-end micro service implementation is actually dependent on this, the large project is broken down into relatively independent micro applications, which is divided into a domain.

reference

  1. www.yuque.com/mayiprotote…

  2. www.infoq.cn/article/a7e…

  3. Hexagonal Architecture by example – a hands-on introduction

  4. Jishuin.proginn.com/p/763bfbd5e…