field driven design and development combat

Background

The central content of domain driven design (DDD) is how to map business domain concepts into software artifacts. Most of the books and articles on this subject are based on Eric Evans's book, Field-driven design, which focuses on domain modeling and design from a conceptual and design perspective. These books discuss the main contents of DDD, such as entities, value objects, services, or the concepts of common languages, defined contexts (bounded context), and protective layers (anti-corruption Layer).

The purpose of this paper is to explore the field modeling and design from the perspective of practice, involving how to deal with the domain model and implement it realistically. We will look at the guidelines, best practices, frameworks, and tools available to the technical directors and architects in the implementation process. Domain-driven design and development are also subject to some architectural, design, and implementation implications, such as:

Business Rules

Persistence of

Cache

Transaction management

Safety

Code generation

Test-driven development

Refactoring

This article discusses how these different factors affect the overall lifecycle of the project implementation, and what the architect should seek in achieving a successful DDD. I will first list the typical features that the domain model should have, and when to use the domain model in the enterprise (as opposed to using a domain model at all, or using a domain model for anaemia).

The article includes a loan processing example application that demonstrates how to apply design positions, and the development best practices discussed here, to real-world-driven development projects. The example application uses some framework to implement the loan processing domain model, such as spring, Dozer, spring Security, JAXB, Arid POJOs, and Spring Dynamic Modules. The sample code is written in Java, but for most developers, the code is easy to understand, regardless of the language background.

Introduction

The domain model brings some benefits, including:

Helps the team create a common model that both the business and IT departments can understand, and use the model to communicate business requirements, data entities, and process models.

The model is modular, extensible and maintainable, while the design also reflects the business model.

Improve the reusability and testability of the business domain objects.