Coding for domain-driven design: Techniques for data-focused development

This year, Eric Evans has groundbreaking software design books "Domain-driven design:tackling complexity in the Heart of Software" (Domain-driven design: a response to the core complexity of software) (Addis On-wesley professional,2003, amzn.to/ffl1k) ushered in its 10 anniversary of the publication of the year. In this book, Evans shares his years of experience in directing large enterprises to complete the process of building software. He then spent more time thinking about how to generalize the patterns that helped these projects succeed-interacting with customers, analyzing the enterprise issues to be addressed, building teams, and architecting the software architecture. The focus of these patterns is the domain of the enterprise, which collectively forms the domain-driven design (DDD). With DDD, you can model the problematic domain. These patterns are created by abstracting your knowledge of the domain. Even today, rereading Martin Fowler's preface and the preface to Evans can still gain a rich overview of the nature of DDD.

In this column and the next two columns, I'll share some of the guiding principles that have helped my data-focused Entity Framework brain keep a clear mind as I proceed to get my code to benefit from some of the DDD technology patterns.

Why do I pay attention to DDD?

My introduction to DDD was excerpted from a short video interview with Jimmy Nilsson posted on infoq.com. Jimmy Nilsson is a respected architect in the. NET community (and elsewhere) who talked about LINQ to SQL and Entity framework (BIT.LY/11DDZUE). At the end of the interview, Nilsson was asked to list his favorite technical books. He replied, "My favorite computer book is the" Domain-driven design "of Eric Evans (field-driven). I think it's as wonderful as poetry. It is not only the content is splendid, but also has the poem General charm, lets the person best-loved. "The Poetic beauty!" At the time, I was writing my first technical book "Programming Entity Framework" (Entity Framework Programming) (O ' Reilly media,2009), which sparked my interest. So I went to read a little Evans book to see how it was written. Evans is a beautiful and fluent author, coupled with his sharp and natural insights in the field of software development, readers experience the full pleasure of reading this book. What struck me, however, was what I had read. Evans is not only a good writer, but also the content of the book is very attractive to me. He talked about building relationships with customers and really understanding their business and business problems (related to problematic software), not just writing code. This view has played a pivotal role in my 25 years of software development career. I want to achieve more.

I lingered on the edge of the DDD field for many more years and began to learn more-I met Evans at a meeting and then attended his four-day immersion seminar. Although I am far from being an expert on DDD, I find that the "defined context" pattern can be used immediately when trying to transform my software creation process into a more organized and manageable structure. You can read the theme of my January 2013 column, "The context shrink EF model defined using DDD" (Msdn.microsoft.com/magazine/jj 883952).

Since then, I have made a further step in the study of DDD. I was fascinated by DDD and got a lot of inspiration from it, but I struggled with the data-driven approach to understanding some of the technologies that could drive success. There seems to be a lot of developers having the same problem, so I want to share in Evans and many other DDD practitioners and teachers (including Paul Rayner, Vaughn Vernon, Greg Young, Cesar de la Torre and Yves Reynho UT) The generous help and interest of the lessons learned.

Forgetting persistence when modeling a domain

Modeling for a domain is a task that focuses on the enterprise. When designing types and their properties and behavior, I am very inclined to consider how relationships work in the database and how my chosen Object Relational Mapping (ORM) framework (i.e. the Entity framework) will handle the properties, relationships, and inheritance hierarchies that I build. Unless you build software for a company that is engaged in data storage and retrieval (like Dropbox), data persistence is only supported in your application. This is much like invoking the weather source API to show the current temperature to the user, or sending data from your application to an external service (possibly the registration information on meetup.com). Of course, your data may be more complex, but using the context of DDD to define methods, and by focusing on behavior and following the DDD guidance when building types, persistence may be much simpler than the system you build today.

If you have studied ORM (for example, understanding how to configure database mappings using the Entity Framework Fluent API), you should be able to implement persistence as needed. The worst case scenario is that you may need to make some adjustments to your class. In extreme cases (for example, when using the old database), you can even add a persistence model designed specifically for database mapping, and then use tools such as automapper to resolve mappings between the domain model and the persistence model.

However, these concerns have nothing to do with the business problems your software uses to solve, so persistence should not affect domain design. This is a problem for me because I can't help thinking about how EF will infer its database mappings when I design an entity. So I tried to solve the problem.

Private setters and public methods

Another rule of thumb is to set the property setter as private. Instead of allowing you to randomly set various properties by calling code, you should control the interaction with the DDD object and its associated data by using the method of modifying the property. No, I don't mean Setfirstname and setlastname. For example, you need to consider some rules before you create a new customer, instead of instantiating the new client type and setting its properties. You can place these rules within the customer's constructor, use the Factory pattern method, and even include the Create method in the customer type. Figure 1 shows the Customer type defined by the DDD pattern of the aggregation root (that is, the "parent" of the object graph, also known as the "root entity" in DDD). Customer properties have private setters so that only other members of the customer class can directly affect these properties. The class exposes a constructor to control its instantiation and hides the parameterless constructor (the Entity Framework needs) as an internal constructor.