Metadata
- Author: Vaughn Vernon
- Full Title:: Domain-Driven Design Distilled
- Category:: đź“šBooks
- Finished date:: 2023-02-02
Highlights
• Software development is considered a cost center rather than a profit center. Generally this is because the business views computers and software as necessary nuisances rather than sources of strategic advantage. (Location 236)
The database is given too much priority, and most discussions about the solutions center around the database and a data model rather than business processes and operations. (Location 241)
Developers don’t give proper emphasis to naming objects and operations according to the business purpose that they fill. This leads to a large chasm between the mental model that the business owns and the software that developers deliver. (Location 243)
that the imagined economy of No Design is a fallacy that has cleverly fooled those who apply the pressure to produce software without thoughtful design. (Location 262)
The alternative to good design is bad design, not no design at all. (Location 266)
Your organization can’t excel at everything and shouldn’t even try. So you choose wisely what should be part of your Core Domain and what should not. This is the primary value proposition of DDD, and you want to invest appropriately by committing your best resources to a Core Domain. (Location 351)
Context. It is possible that one team could work on multiple Bounded Contexts, but multiple teams should not work on a single Bounded Context. Cleanly separate the source code and database schema for each Bounded Context in the same way that you separate the Ubiquitous Language. (Location 365)
The business’s department or work group divisions can provide a good indication of where model boundaries should exist. (Location 396)
- Note: El efecto este del software teniando la pinta que tiene la org
You are using DDD because the business model complexity is high. (Location 495)
Core Domain (Location 555)
Don’t limit your Core Domain to nouns alone. Rather, consider expressing your Core Domain as a set of concrete scenarios about what the domain model is supposed to do. (Location 562)
model. In the end the code is the model and the model is the code. (Location 579)
This unit-test-based approach to acceptance testing accomplishes the same goal as the executable specification. The advantage here may be the ability to write this kind of scenario validation more rapidly but at the cost of some readability. Still, most Domain Experts should be able to follow this code with some help from the developer. When using this approach it would probably work best to maintain the document form of the scenario associated with the validation code in comments, as seen in this example. (Location 652)