Applying Domain-Driven Design and Patterns: With Examples in C# and .NET - page 95

Summary

Now I'm back again; Jimmy, that is. It's time to summarize the style variations just described by Mats, Frans, and Ingo. Which one is best? It depends! Life is full of tradeoffs! Would you like to hear some more very good and useful nuggets? What is good and what is bad about the different styles? Here's another good nugget: Make your own decisions, for your own specific situations.

I'm sure you got my point here. As you understand, I didn't ask my friends to write some about their ideas on the subject to see which approach is best. I asked them write about this problem to get you some exposure to other points of view and some inspiration from other styles.

If I were to write micro-summaries of their styles, I would express it like this. In Mats' case, I believe the title is a great summary, namely "Object-Oriented Data Model, Smart Service Layer, and Documents." Mats is fond of locating the behavior in the Service Layer and seeing the Domain Model as an object-oriented representation of the data. "Documents" is about the exchange format between different tiers.

Frans stresses the importance of using the power of the database and that the representation in the database is the true one.

Ingo talks about the importance of finding the right abstractions and that you shouldn't expect to be able to use a single standard style for all situations. Add to that a big chunk of pragmatism .

Appendix B. Catalog of Discussed Patterns

This appendix is a catalog of the patterns that are discussed in the book. No new information is to be found here; instead, this is intended to be a service to the reader. You'll find here the source of the pattern where you can read more, a very condensed description, and most often a URL where you can instantly get more information.

Note

You find this appendix online as well if you would like it to be clickable: www.jnsk.se/adddp/patterns

When the description is written between quotation marks, that means that the description is taken directly from the provided URL (or from the mentioned book's inner cover in the case of some of the [GoF Design Patterns]).

Abstract Factory [GoF Design Patterns]

"Provides an interface for creating families of dependent objects without specifying their concrete classes."

http://patternshare.org/default.aspx/Home.GOF.AbstractFactory

Aggregate [Evans DDD]

Cluster Entities and Value Objects with a boundary. Let one of the Entities in the Aggregate be the access point (the Aggregate root).

http://patternshare.org/default.aspx/Home.DDD.Aggregates

Bounded Context [Evans DDD]

Define a boundary around a distinct model.

http://patternshare.org/default.aspx/Home.DDD.BoundedContext

Chain of Responsibility [GoF Design Patterns]

"Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it."