ATL ALT.NET: April Meetup: Domain-Driven-Design

Hello ATL ALT.NET programmers,

We had great discussion in February, much of it centered around Domain-Modeling and Domain-Driven-Design. As such, let's do another book study for April. Details below.

IMPORTANT: The North Avenue room requires you to pay by credit card
Manuel's does not charge us for the room, however they expect everyone to buy food and/or drink, so please help keep this room free by doing so.

Agenda:
07:00 PM - 08:15 PM: Dine, Drink, Socialize in the North Avenue Room
08:15 PM - 09:30 PM: Focused discussion on Domain-Driven Design
09:30 PM - 10:00 PM: Winding down

Required Reading
InfoQ has created a mini-version of this book, which covers the basic concepts at a high level and is only 91 pages long:

https://www.infoq.com/... (https://www.infoq.com/minibooks/domain-driven-design-quickly)

Recommended Reading
The full book is called "Domain-Driven Design: Tackling the Complexity in the Heart of Software", by Eric Evans.

Read its full TOC and preview many pages here:
https://books.google.c... (https://books.google.com/books?id=7dlaMs0SECsC&printsec=frontcover)

About Domain-Driven Design

From Wikipedia:

https://en.wikipedia.o... (https://en.wikipedia.org/wiki/Domain-driven_design)

Domain-driven design (DDD) is an approach to the design of software, based on the two premises that complex domain designs should be based on a model, and that, for most software projects, the primary focus should be on the domain and domain logic (as opposed to being the particular technology used to implement the system). The term was coined by Eric Evans in his book of the same title.

In the book Domain-Driven Design, a number of high-level concepts and practices are articulated, such as ubiquitous language meaning that the domain model should form a common language given by domain experts for describing system requirements, that works equally well for the business users or nsponsors and for the software developers. The book is very focused at describing the Domain layer which is one of the common layers in an object-oriented system with a multilayered architecture. In DDD, there are artifacts to express, create, and retrieve domain models:

Entities (a.k.a. Reference Objects): An object in the domain model that is not defined by its attributes, but rather by a thread of continuity and identity.
Value Objects: An object that describes a characteristic of a thing. Value Objects have no conceptual identity. They are typically read-only objects and may be shared using the Flyweight design pattern.
Services: When an operation does not conceptually belong to any object. Following the natural contours of the problem, you can implement these operations in services. The Service concept is called "Pure Fabrication" in GRASP.
Repositories: methods for retrieving domain objects should delegate to a specialized Repository object such that alternative storage implementations may be easily interchanged.
Factories: methods for creating domain objects should delegate to a specialized Factory object such that alternative implementations may be easily interchanged.

Additional Resources

Read more about Domain-Driven Design on the web site:

https://domaindrivende... (https://domaindrivendesign.org/)

Listen to an interview with Eric Evans here:

https://domaindrivende... (https://domaindrivendesign.org/events/qcon2008SF/eric_evans/index.html)

Listen to Eric Evans interviewed on .NET Rocks in 2007 here:

https://www.dotnetrock... (https://www.dotnetrocks.com/default.aspx?showNum=236)

Watch more videos and interviews about DDD from OOPSLA 2007 and other events here:

https://domaindrivende... (https://domaindrivendesign.org/events/oopsla2007/oopsla2007.html)