Bing. O.

I am so tired of these sorts of shallow analyses from people that think their screw-ups are actually caused by EDAs or micro services or whatever. They’re even totally transparent about the fact that they did because they heard cool things but never say “so we sat down to learn about best practices, what the current state of the art is, and considered how our use cases matched the architecture”

They just say “we thought it would be cool so we just started doing it and it sucked - here’s why that’s an inherent problem of the architecture and not in any way related to our behavior”.

Yes. If you take a team of people who build n-tier and hexagonal MVC monolithic apps, and then tell them to build micro services, they’re going to build a bunch of n-tier or hexagonal MVC monolith candidates and eventually end up with a single service that does too much and ultimately becomes the monolith.

Yes. If you take a team that does 100% synchronous HTTP interfaces, SOAP or ReST, and then tell them to build microservices, they’re going to daisy chain those microservices via synchronous HTTP interfaces, and if you tell them to build an EDA they are going to build an EDA that attempt to replicate all of the aspects of their synchronous HTTP interfaces with busy polling loops.

So stop doing that and actually do the hard thing of learning fundamentally different architecture, techniques, technologies, trade offs, best practices, operational patterns, design patterns, and heuristics and principles for managing software. Learning is difficult and humbling. But it sure beats writing ignorant articles like this.

Direct Rendering Manager

There’s already a document database engine in postgres. It already supports bson. It already supports indexes. What the fuck MS?

Honestly this is completely ridiculous. Hypertext using HTML constraints is absolutely insufficient for representing application state. It’s the wrong tool for the job and always has been, because it conflates document structure with semantic meaning.

Said another way, HTML cannot be relied on to capture a representation of application state.

The reason REST doesn’t use HTML in most contexts is because applications don’t use HTML in most contexts anymore.

Demanding that application representation use a specific encoding strategy is ridiculous and misses the point entirely, which is that HTTP is no longer the right protocol for the job.

It means do not test HOW it is done, only test WHY it is done. Obviously you cannot test an abstract interface, only an implemented one. However, you should not be testing HOW it is implemented. Instead, you should be testing that given X input you get Y output based on the expectations set in the interface.

For example, take method F(x, y) that is designed to take in an identifier x and use it to fetch you a record from some persistence object y. Testing the interface of F(x, y) would mean testing that given the input x you get what you expect from the persistence object y. Testing the implementation would mean testing that F(x, y) issues a call to a specific method of y. For example, if y has an interface with methods getRecordById, getAllRecords, and searchRecords, testing the implementation means asserting which of these methods gets called (usually with a test using a mock object that can be interrogated in this way). Testing the interface means not caring which of these methods are called when satisfying the request for F(x, y)