Q: In the book "Implementing DDD" you say to do code reviews with domain experts. Really? How?
A: First, I didn't say that.
The point is that business experts can understand tests if the tests follow the language that the experts helped develop and if the tests present 1/5
realistic scenarios with realistic data/information.
I don't know how many times I have seen tests with completely bogus scenarios and data. For example, George Washington and Abraham Lincoln have no value-add as personas in most modern contexts. 2/5
Instead such example data disrupts experts' ability to think through scenarios because the examples are ridiculously unbelievable.
I have written test data generators that randomly produce a range of realistic valid data associated with subjects that, eg, work around HIPAA 3/5
and other privacy restrictions that render production data unusable.
Executives have said: "Wow, that's awesome. Thanks for making us look really smart to our customers."
You would benefit from thinking in "acceptance tests" using the Specification by Example style 4/5
with Given-When-Then. If you look at my "DDD Distilled" book I discussed SbE and even how to simulate GWT using a unit test framework. See Chapter 2. 5/5
• • •
Missing some Tweet in this thread? You can try to
force a refresh
In Implementing #DDDesign why use Anticorruption Layer rather than a Repository to integrate with another Bounded Context?
Typically the Repository pattern is used as an Adapter in front of a database. In general you could think of a Repository as an AcL over a database. 1/6
But then again, an AcL is at least both of these: (1) an Adapter, and (2) a Translator. Typically a Repository doesn't translate from database data into a model's data. Usually database data is at most reshaped when hydrating 2/6
models. In other words, you think of an AcL more as a translator between two different model languages, where one language might not be carefully defined. A Repository isn't translating between languages, just adapting database data shapes to/from domain model data shapes. 3/6
1. Technical component name in protocol. 2. Task doesn't describe the eventual completion of an async value. 3. Mono " " " " " " " ... 4. Flux " " " " " " " ... 5. The word Get/get/GeT/gEt/geT/etc.
Many such names become glyphs. They only represent something that you intend, they don't describe what you intend. Your brain will ultimately filter this noise out of your way, because they have no meaning.