Author: Brandon Pearman
The views expressed here are mine alone and do not reflect the view of my employer.
- Coined Domain Driven Design
- If you don't have a good abstraction, then don't use any abstract.
- The heart of software is its ability to solve domain-related problems for its user.
- It takes fastidiousness to write code that doesn’t just do the right thing but also says the right thing
- To communicate effectively, the code must be based on the same language used to write the requirements—the same language that the developers speak with each other and with domain experts.
- documenting exclusively through code has some of the same basic problems as using comprehensive UML diagrams
- A document shouldn’t try to do what the code already does well.
- you may hear the UBIQUITOUS LANGUAGE changing naturally while a document is being left behind.
- you can improve a design by refactoring, and that you will do this often and rapidly. But past design choices make refactoring itself either easier or harder.
- To be open to change, a design must be easy to understand.
- Every additional concept that has to be held in mind in order to understand an object contributes to mental overload.
- A lot of overengineering has been justified in the name of flexibility. But more often than not, excessive layers of abstraction and indirection get in the way. Look at the design of software that really empowers the people who handle it; you will usually see something simple.
- Type names, method names, and argument names all combine to form an INTENTION REVEALING INTERFACE.
- Even within a MODULE, the difficulty of interpreting a design increases wildly as dependencies are added. This adds to mental overload, limiting the design complexity a developer can handle. Implicit concepts contribute to this load even more than explicit references.
- Dependencies on other classes within the same module are less harmful than those outside. Likewise, when two objects are naturally tightly coupled, multiple operations involving the same pair can actually clarify the nature of the relationship. The goal is not to eliminate all dependencies, but to eliminate all nonessential ones.
- Book - Domain-Driven Design: Tackling Complexity in the Heart of Software
- Book - Domain-Driven Design Reference: Definitions and Pattern Summaries