List of books (2nd edition)

• 
  Peopleware: Productive Projects and Teams
  
  This is simply the best book about people and software that I've read to date. The authors use knowledge drawn from their years as software engineers and consultants to explore many questions about productivity. The book shows that leaders and managers should be constantly re-evaluating their practices (especially those that are taken as common sense) in order to maintain people at their balance point and, consequently, obtain the best results in the projects. Although the ideas in the book are focused primarily on software teams, they can also be applied for teams in general.
• 
  Agile Software Development, Principles, Patterns, and Practices
  
  This book by Uncle Bob was published shortly after the publication of the Agile Manifesto. It presents many design patterns and demonstrates how to use them by showing their application in real projects. All case studies are presented using principles of XP, like TDD and pair programming. The examples can become a bit tiresome by the end of the book, but the sections that present the design patterns are worth reading.
• 
  The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact
  
  A really practical book with many useful tips. Altough not extensive, the text covers a few different topics, offering advices that can easily be applied to everyday work. A light read that indeed has the potential to increase the effectiveness of any software engineer.

Making implicit concepts explicit

Many transformations of domain models and the corresponding code happen when developers recognize a concept that has been hinted at in discussion or present implicitly in the design, and they then represent it explicitly in the model with one or more objects or relationships.

Digging out concepts

Developers have to sensitize themselves to the hints that reveal lurking implicit concepts, and sometimes they have to proactively search them out. Most such discoveries come from listening to the language of the team, scrutinizing awkwardness in the design and seeming contradictions in the statements of experts, mining the literature of the domain, and doing lots and lots of experimentation.

How to model less obvious kinds of concepts

Explicit constraints

Constraints make up a particularly important category of model concepts. They often emerge implicitly, and expressing them explicitly can greatly improve a design.

Here are some warning signs that a constraint is distorting the design of its host object.

1. Evaluating a constraint requires data that does not otherwise fit the object's definition.
2. Related rules appear in multiple objects, forcing duplication or inheritance between objects that are not otherwise a family.
3. A lot of design and requirements conversation revolves around the constraints, but in the implementation, they are hidden away in procedural code.

When the constraints are obscuring the object's basic responsibility, or when the constraint is prominent in the domain yet not prominent in the model, you can factor it out into an explicit object or even model it as a set of objects and relationships.

Processes as domain objects

What I am talking about here are processes that exist in the domain, which we have to represent in the model. When these emerge, they tend to make for awkward object designs.

A SERVICE is one way of expressing such a process explicitly, while still encapsulating the extremely complex algorithms.

When there is more than one way to carry out a process, another approach is to make the algorithm itself, or some key part of it, an object in its own right. The choice between processes becomes a choice between these objects, each of which represents a different STRATEGY.

The key to distinguishing a process that ought to be made explicit from one that should be hidden is simple: Is this something the domain experts talk about, or is it just part of the mechanism of the computer program?

SPECIFICATION

Business rules often do not fit the responsibility of any of the obvious ENTITIES or VALUE OBJECTS, and their variety and combinations can overwhelm the basic meaning of the domain object. But moving the rules out of the domain layer is even worse, since the domain code no longer expresses the model.

A SPECIFICATION is a predicate that determines if an object does or does not satisfy some criteria.

The SPECIFICATION keeps the rule in the domain layer. Because the rule is a full-fledged object, the design can be a more explicit reflection of the model.

Applying and implementing SPECIFICATION

Much of the value of SPECIFICATION is that it unifies application functionality that may seem quite different. We might need to specify the state of an object for one or more of these three purposes.

1. To validate an object to see if it fulfills some need or is ready for some purpose
2. To select an object from a collection (as in the case of querying for overdue invoices)
3. To specify the creation of a new object to fit some need

These three uses — validation, selection, and building to order — are the same on a conceptual level. Without a pattern such as SPECIFICATION, the same rule may show up in different guises, and possibly contradictory forms. The conceptual unity can be lost. Applying the SPECIFICATION pattern allows a consistent model to be used, even when the implementation may have to diverge.

Eric Evans, "Making Implicit Concepts Explicit", in Domain-Driven Design: Tackling Complexity in the Heart of Software, 205-227.