From martinfowler.com on "Command Query Responsibility Segregation", or CQRS:

The mainstream approach people use for interacting with an information system is to treat it as a CRUD datastore. By this I mean that we have mental model of some record structure where we can create new records, read records, update existing records, and delete records when we're done with them. In the simplest case, our interactions are all about storing and retrieving these records.

As our needs become more sophisticated we steadily move away from that model. We may want to look at the information in a different way to the record store, perhaps collapsing multiple records into one, or forming virtual records by combining information for different places. On the update side we may find validation rules that only allow certain combinations of data to be stored, or may even infer data to be stored that's different from that we provide.

As this occurs we begin to see multiple representations of information. When users interact with the information they use various presentations of this information, each of which is a different representation...

This structure of multiple layers of representation can get quite complicated, but when people do this they still resolve it down to a single conceptual representation which acts as a conceptual integration point between all the presentations.

The change that CQRS introduces is to split that conceptual model into separate models for update and display, which it refers to as Command and Query respectively following the vocabulary of CommandQuerySeparation. The rationale is that for many problems, particularly in more complicated domains, having the same conceptual model for commands and queries leads to a more complex model that does neither well.

I saw this acronym for the first time today in a SO question about Azure Service Fabric, and my HOT TAKE!!11! was, "Who in the world doesn't do this?"

There are two main data transformations that happen in essentially all of my controller code. For GETs, I'm usually flattening a "database is truth" model into a data payload, stripped of stuff like, "LastModifiedBy" (or anything not needed by the client), but also of complex relationships with child objects. That is, when Entity Framework (or any POCO-returning library) gives me, say, an address' stateOrProvince as an entity, I usually flatten that to a StateName and StateId at the top level of a client-ready DTO for Addresses (or at the Address level on a collection of Addresses attached to a client).

The second is when I return changes to these DTOs. There, the PUT (or PATCH) command often isn't strictly RESTful either [using the database as The Source of Truth]. If I'm returning the ever-proverbial Contact with three Addresses, I don't typically call an Addresses endpoint with a PUT thrice, and then follow up with another PUT to Contacts. I'll send up a DTO that's essentially CompositeContactWithAddressesAndOtherJive (but with a better name, like ContactDTO). And though if I'm trying to keep our stack small in cases where team familiarity with SQL isn't a strong suit, I will, occasionally, still hit EF repository collections, I usually prefer to write the INSERT/UPDATE SQL by hand and perform what needs doing in as few optimized calls as possible. The move away from the ORM for PUTs hurts if you ever want to swap out your database engine, of course, but who swaps out their database engine? Talk about premature optimizations. Why should nearly every PUT suffer when you're likely hiring for SQL proficiency? For a clean object model? Stop it. Use your team's skills.

There is nothing that, in my experience, causes performance bottlenecks as quickly as folks blindly falling back on performing Commands (actions that "Change the state of a system but do not return a value") via fully hydrated ORM objects. Oh, the humanity.

Treating your PUTs and PATCHes as separate models from your GETs (or at least separate models from those in your database schema) allows you to spare yourself such madness.

Labels: coding, CRUD, fowler, style

I think I was reading about CommonMark when I saw this mentioned.

Sad because true?

Honestly, I think CommonMark is probably a pretty good idea, all things considered. There are people that are going to get concerned with a "spec" that's, as CommonMark puts it, "ambiguous". You don't want strange edge cases that seem to conflict with reasonably hard and fast rules. I think the best complaint I've seen (and I can't dig the source back up in 10 mins of googling) is the "underline for headers" issue.

What do you do here?

This is a header. Or is it the last thing in a section before a horizontal line?
--------------------------------------------------------------------------------
I'm not sure. You tell me.

Apparently the original spec didn't address many edge cases like this, and you'd have to go to the code. I can't recall why that code wasn't good enough, other than folks occasionally disagreeing with it. And different users do have different needs, so I think that's a fair complaint.

And most importantly for coders, CommonMark gives you a test suite. We like to have explicit pass/fail conditions. You're only as good as your metrics and QA.

But yeah, any time somebody's providing something called Babelmark to help you see what's going on in different flavors of a markup format with unresolved edge cases, you've got a fragmentation problem.

Also worth mentioning: Is HTML a Humane Markup Language? from Atwood. Probably as good a visualization of why we might prefer Markdown to some other markup language that's got some traction right now as I've seen, though Atwood here (contra Atwood now, afaict) strangely decides that HTML is easier to eyeball than Markdown.

In other news, I had this choice definition of POJO open from Martin Fowler's site. I was pretty confident when I read "Anemic Domain Model" that he'd meant Plain Old Java Object, but the backstory is both hilarious and tragic.

POJO An acronym for: Plain Old Java Object.

The term was coined while Rebecca Parsons, Josh MacKenzie and I were preparing for a talk at a conference in September 2000. In the talk we were pointing out the many benefits of encoding business logic into regular java objects rather than using Entity Beans. We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely.

(ー_ー﹡)

Labels: coding, fowler, markdown, standards