4 ms·

Reminds me of the quote: > Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need

Reminds me of the quote: > Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious. -- Fred Brooks, The Mythical Man Month (1975) I don't think they're inherently contradictory. You can have plain data objects representing the domain, and functions that act on these objects representing the behaviors/actions in the domain. You could include these functions as part of the "class" for these objects, and have them return new instances of the class to maintain immutability.

ChicagoDave 6y ago
That evades my point. To a business person, the things they do are more important than data structures. If you try to talk to a subject matter expert, they're going to talk about how their portion of a business works, not list all of the data within their system. The only caveat is if you're talking to a person that's focused on reporting and analytics...then they will be more data focused. But businesses react to analytics, they don't run on it. Operationally, there are a set of events that happen logically from start to finish. You could do all of the data governance you want and if you miss those events and their sequence and impact, you wouldn't know what business you're in. Data accuracy is critical. Data storage is critical. Analytics and warehousing are critical. But none of these things reflect the nature of a business, which are the behaviors of its domain and sub-domains.