<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Communication on communities.abhinav-ja.in</title><link>https://communities.abhinav-ja.in/tags/communication/</link><description>Recent content in Communication on communities.abhinav-ja.in</description><generator>Hugo -- 0.137.1</generator><language>en</language><lastBuildDate>Sat, 17 May 2025 00:00:00 +0000</lastBuildDate><atom:link href="https://communities.abhinav-ja.in/tags/communication/index.xml" rel="self" type="application/rss+xml"/><item><title>Week 2 – Communication and the Use of Language</title><link>https://communities.abhinav-ja.in/book-club/domain-driven-design/week-02/</link><pubDate>Sat, 17 May 2025 00:00:00 +0000</pubDate><guid>https://communities.abhinav-ja.in/book-club/domain-driven-design/week-02/</guid><description>&lt;p>Opening the thread for &lt;strong>Chapter 2 – Communication and the Use of Language&lt;/strong>.&lt;/p>
&lt;p>This chapter moves us closer to the interface between language, code, and clarity. Evans argues that the model should not be something floating outside the implementation, rather the best code should &lt;em>reveal&lt;/em> the model directly. The diagrams and documents we write should support that, not compete with it.&lt;/p>
&lt;p>A few lines that stood out:&lt;/p>
&lt;blockquote>
&lt;p>&amp;ldquo;The vital detail about the design is captured in the code. A well-written implementation should transparently reveal the model underlying it. Supplemental diagrams and documents can guide people&amp;rsquo;s attention to the central points. Natural language discussion can fill in the nuances of meaning.&amp;rdquo;&lt;/p></description></item></channel></rss>