The book "subject-oriented design: patterns, principles and methods"

Writing programs is easy - at least from scratch. But to change the once written program code that was created by other developers or you yourself some six years ago is much more difficult. The program works, but you do not know exactly how. Even referring to subject matter experts does not give anything, since no trace of their usual language has been preserved in the code.

Domain-Driven Design (DDD) is the process of closely aligning software code with the realities of the domain. Thanks to it, adding new features to a software product as it develops becomes as simple as creating a program from scratch. This book is fully consistent with the DDD philosophy and allows developers to move from philosophical reasoning to solving practical problems.

Task space

Before you start developing a solution, you should understand the task. DDD emphasizes the need to delve into the subject area of ​​the business problem - to understand its terminology, to identify the underlying causes behind the need for software development, and to understand what is a success from a business point of view. It is vital that such knowledge of the topic becomes for developers as valuable and appreciated quality as technical knowledge and experience: it gives an opportunity to better understand the subject area and helps to divide a large area into smaller parts.

In fig. B.1 presents a general view of the problem space (problem space) in DDD, which is described in the first part of the book.
')

Decision space

Having a clear idea of ​​the subject area, you can implement a technical solution that is consistent with the subject area using the DDD strategic patterns. Strategic templates allow you to protect the main parts of the system, which are essential for the success of the product, from the influence of non-specialized areas. Due to the isolation of the integral components of the system, their subsequent changes will not be reflected by a rebound on the rest of the system.

At the heart of those key subsystems of your product that are quite complex or will change frequently, the model should be based. Tactical DDD templates along with Model-Driven Design architecture will help you create a useful domain model in the code. The model is the container of all the applied logic, thanks to which the application fulfills all business usage scenarios. The model is separated from technical difficulties, which leaves room for the development and change of business rules and regulations. The model, consistent with the subject area, will make your software easily adaptable and understandable to other developers and business professionals.

In fig. B.2 presents a general view of the solution space (solution space) DDD, which is also described in the first part of the book.

The structure of this book

Part I. Principles and techniques of subject-oriented design.
Part I introduces you to the principles and techniques of DDD.

Chapter 1. What is subject-oriented design?
DDD is a methodology that helps to cope with the problems that arise when creating software for complex subject areas. The first chapter introduces the DDD philosophy and discusses why terminology, collaboration, and context are the most important aspects of DDD and why DDD is much more than just a set of programming patterns.

Chapter 2. Distillation of the problem domain
Mastering a complex data domain is extremely important for creating user-friendly software. The process of processing knowledge with the participation of subject matter experts is the key to this knowledge. Chapter 2 details the techniques that allow the development team and subject matter experts to collaborate, experiment and learn together to create effective domain models.

Chapter 3. Concentration on the core of meaning
Chapter 3 describes how to distill a large data domain and identify the most important part of the task — the core domain. Then we explain why time and effort should be spent primarily on the semantic core, isolating it from less important supporting domains and generic domains.

Chapter 4. Model Based Design
Colleagues from the business own the analytical model (analysis model) of the subject area. Developers have their own version of this model - a software model (code model). However, for successful cooperation of two teams - developers and business professionals - a single model is needed. A single language (ubiquitous language) and a shared idea of ​​the problem space is what connects the analytical model with the program model. The idea of ​​a single language is central to DDD and serves as the basis of the entire methodology. A common language for describing terms and concepts of the subject area, jointly developed by a team of developers and business experts, is essential for discussing complex systems.

Chapter 5. Patterns of the implementation of the subject model
Chapter 5 is a detailed story about what the domain model (domain model) is responsible for and what role the application plays. It also presents various patterns that can be applied when implementing a domain model, and describes the situations for which they are most appropriate.

Chapter 6. Ensuring the integrity of domain models with limited contexts
In large solutions there may be more than one model. It is important to preserve the integrity of each model in order to avoid ambiguities in the language and inappropriate use of concepts by different teams. The strategic pattern called “bounded context” was created specifically to isolate and protect the model in context, while providing the opportunity for it to work with other models.

Chapter 7. Context Cards
A context map, which is used to understand and reflect the relationships between different models in an application and how to integrate them, is a critical element of strategic design. Context maps cover not only the technical aspects of integration, but also the political relations between the teams. They give a general picture of the landscape, which helps teams understand their model in the context of the landscape as a whole.

Chapter 8. Application Architecture
The application must be able to use the domain model to meet the requirements of business use cases. Chapter 8 introduces you to architectural patterns that allow you to structure your application in such a way as to preserve the integrity of the domain model.

Chapter 9. Typical problems for teams starting to apply subject-oriented design
Chapter 9 describes the typical difficulties faced by teams using DDD, and explains why it is so important to know when this approach should not be used. It also explains why the powerful DDD toolkit in the application to simple tasks can generate redundant and unnecessarily complicated systems.

Chapter 10. Applying DDD Principles, Techniques, and Templates
Chapter 10 tells how to convince others of the benefits of DDD and begin to apply the principles and techniques of this approach in their projects. It explains why attempts to create an ideal domain model are not as valuable for creating high-quality software as research and experiments.

Part II. Strategic Patterns: Limited Contexts Interaction
Part II shows how to integrate limited contexts, and describes in detail possible approaches to constructing limited contexts. Here are examples of code that demonstrate the subtleties of integration with existing applications, and describes techniques that allow communication across context boundaries.

Chapter 11. Introduction to Integrating Restricted Contexts
Modern applications are distributed systems that require reliability and scalability. This chapter brings together the theory of distributed systems and DDD so that you can take the best of both worlds.

Chapter 12. Integration through messaging
Here, as an illustration, we create an application that, using the example of organizing a message bus for asynchronous messaging, shows how the principles of building distributed systems are used in conjunction with DDD.

Chapter 13. Integration with RPC and REST via HTTP
Another application example demonstrates an alternative approach to creating asynchronous distributed systems: instead of the message bus, standard protocols are used, such as the HTTP protocols (Hypertext Transport Protocol), REST, and Atom.

Part III. Tactical patterns: creating effective domain models
Part III covers design patterns that can be used to build a domain model in the program code, along with patterns for maintaining the model and patterns for managing the life cycle of the domain objects that make up the model.

Chapter 14. Introduction to standard domain modeling blocks
This chapter introduces you to all the tactical patterns that are at your disposal and allow you to create effective domain models.
The practical recommendations given here help to get more manageable and expressive models in the program code.

Chapter 15. Value Objects
Chapter 15 serves as an introduction to value objects — DDD modeling constructs that allow you to represent such individualized domain concepts as money.

Chapter 16. Entities
Entities are entities that have an identity, such as customers, transactions, and hotels. This chapter contains many examples and covers a number of additional implementation patterns.

Chapter 17. Domain Services
Some domain concepts are stateless operations that are not related to any value objects or entities. They are known as domain services.

Chapter 18. Domain Events
In many subject areas, a deeper understanding can be achieved, if not limited to the study of entities alone, but to pay close attention to events. This chapter presents a design pattern based on domain events, which allows you to more clearly reflect events in the domain model.

Chapter 19. Units
Aggregates (aggregates) - a collection of objects that represent the concept of the domain. In essence, the aggregates limit the zone of consistency around the invariants. This is the most powerful tactical pattern.

Chapter 20. Factories
Factories are a life-cycle organization pattern that separates the construction of complex domain objects from their use.

Chapter 21. Repositories
Repositories (repositories) act as intermediaries between the domain model and the data model. They provide isolation of the domain model from any infrastructural features and tasks.

Chapter 22. Event Registration
Event registration (event sourcing), as well as the events themselves, which are described in Chapter 18, is a useful technique that makes it possible to focus in the program code on events that occur in the subject area. The registration of events is a step beyond the limits of the domain events, since it stores the state of the domain model as events. This chapter includes a number of examples, including those using a specialized event repository.

Part IV. Efficient application design patterns
Part IV presents patterns for constructing applications that use a domain model and protect its integrity.

Chapter 23. Designing User Interfaces for an Application
The user interface of a system consisting of many limited contexts often requires combining data from several contexts, especially when limited contexts form a distributed system.

Chapter 24. CQRS: Restricted Context Architecture
CQRS (Command Query Responsibility Segregation - division of responsibility into teams and requests) is a design pattern that creates two models in place of one. Where there used to be a single model that handles two different reading and writing contexts, two separate models are created — for processing commands and for servicing requests, on the basis of which reports are generated.

Chapter 25. Commands: Application Service Templates for Processing Business Use Cases
It describes the differences between applied and substantive logic. Having a clear understanding of these differences, you will be able to save your model from spreading and simplify the maintenance of the system.

Chapter 26. Requests: Subject Reporting
In order to make well-considered decisions regarding product development and business, business professionals need information. This chapter demonstrates the numerous methods of creating reports that provide the required level of business information.

Who is this book for?

The main topics of DDD - techniques, patterns and principles - are discussed here along with personal experience and interpretation of the methodology. The purpose of the book is to help those who are interested in this approach or are just starting to use it. It does not replace Erik Evans1's “Object-Oriented Design” book, but it simply and intelligibly expounds the concepts introduced by Evans, accompanying the description with practical examples, so that any developer can quickly get up-to-date before proceeding to a deeper study of this methodology.

The book is based on the personal experience of the author, obtained using the subject of discussion. Experts with extensive experience in the use of DDD may not agree with something on the author, but even they are likely to be able to learn something useful from here.

about the author

Scott Millett (Scott Millett) - director of information technology company Iglu.com. Uses .NET, starting with version 1.0. In 2010 and 2011 he was awarded the ASP.NET MVP Award. He is also the author of the book "Professional ASP.NET Design Patterns and Professional Enterprise .NET".

About co-author
Nick Tune with passion is committed to solving the problems facing the business, creating impressive software products and constantly learning. Creating software is his dream job. So far, the brightest stage of his career was working at 7digital, where he was part of self-organizing teams that were involved in solving business problems and deployed their applications on the production site up to 25 times a day. He expects that in the future he will have to work on exciting new software products side by side with other enthusiastic people and the opportunity to constantly improve in solving various tasks.

About science editor
Antony Denier (Antony Denyer) has been a developer, consultant and coach and has been professionally developing software since 2004. He worked on a number of projects where ideas and techniques of subject-oriented design were effectively applied. Some time ago he began to actively defend the use of CQRS and REST in most of his projects.

»More information about the book can be found on the publisher's website.
» Table of Contents
» Excerpt

For Habrozhiteley 20% discount coupon - DDD