[CodexArcanum]

I see we're rebranding SOA/microservices again.

I did enjoy reading the preview book for EventStorming, seems like a decent format for getting stakeholders involved in the design process and capturing business details. I'm pretty sure you can also do this with an org-mode doc and emailing the right questions to the right people, but discovery is hard and having a big post-it note brain storm with 30 people does sound like more fun!

I don't know, I feel like tech people are regularly amazed that other people can describe the events, processes, and data needs of their jobs if you just ask them. Likewise I grant that many people are poorly onboarded and end up "faking it to make it" in their careers. I've seen similar "people lighting up as they finally understand what the company does" moments through the use of literally any form of high-level modeling of the business. People are starved for context at most jobs.

[bennyp101]

I tried the EventStorming a few years ago with a dept for working out a new system , it was really eye opening how everyone referred to things - seeing it all laid out made them realise they all did things slightly differently, and referred to things differently. It was fun and very useful to not just me, but them as well

[colonelpopcorn]

I don't think I can upvote this hard enough. Getting people to think and talk about what they do in context provides a lot of great insight in how to use tech (or not use it) to solve their problems.

[namaria]

I agree, but I've experienced quite often people refusing to care about context. Often some variant of "I don't know about that, I only do X".

[wil421]

Or “I have to X, Y, and Z. To get the result I want.” Only to find out X and Y haven’t mattered in years and they only do it because it’s on the form.

[namaria]

Well that's rote learning for you, but I don't think it's the same issue as people avoiding knowing about context. I've met very smart people who know their silos quite well and refuse to acknowledge any picture bigger then they need to, strictly speaking.

[bradhe]

“Getting stakeholders involved in the design process” is giving me BDD flashbacks. It’s Gherkin all over again.

[marcosdumay]

The good parts of SOA, the event and CQRS stuff, data administration (and curation recently), and BDD all reduce to the same set of ideas.

But then there are always people that look at those and keep exactly the bad parts. Like the links from the article, that all but define event-driven architectures as software that use Kafka.

[rswskg]

haha, weren't they meant to be writing the tests by now?

[mrkeen]

I was happy that we got rid of Cucumber at my workplace in 2018.

Two weeks ago at my new workplace I sat through a colleague's tech talk about how to test with Cucumber.

[yosamino]

A bit naviely using cucumber seems like a good idea. Could you share some advice or resources on why it might not be ?

[mrkeen]

You're setting up an extra layer of difficulty around the system. Sure, the English is 'easy' to read, as long you do the hard work of converting the test cases to English. Then when something goes wrong or you want to know what's really going on, you have to translate from English back into the system's language to think about it.

[dragonwriter]

The utility of Cucumber, it seems to me, is that it makes it more likely that the business level description of the test cases is maintained in sync with the technical implementation, which (if the test cases aren’t squirreled away in the tech team away from the eyes of people responsible directly to customers) makes it less likely that you experience drift between what you are testing and what users rely on the system to do.

Its not that it makes testing easier, its that, in the right social context, it makes testing more likely to be aligned with business intent.

[conradfr]

Maybe they'll get ChatGPT to write them for them.

[rswskg]

Maybe we will?

[mcphage]

> I see we're rebranding SOA/microservices again.

The rebrandings will continue until morale improves.

[erikerikson]

I disagree. EDA is about how microservices are integrated and, if you establish it, how consistency between them is maintained. Note the talk of ordering guarantees and the like. See also event sourcing and the shifting of responsibility for maintaining data stores: historically data stores were maintained by an authoritative microservice while in many EDA systems multiple copies of the same data stores exist across the system.