3 ms·

I can't agree more. I'm still to see a testing tool that can be used for specification and used by end users. Today everything is developer centric. Maybe there

by neves 8y ago

I can't agree more. I'm still to see a testing tool that can be used for specification and used by end users. Today everything is developer centric. Maybe there's no escape to this. The solution is really to make your developers understand the business.

pcm191 8y ago
Hi Neves Could not agree more. That's why Andy Pols and I recast the BA role as a Business Coach back in the day. Chris
endiangroup 8y ago
Thats where things like Domain Driven Design are going, and really it makes a lot of sense. Why express and model your domain in terms outside of it? Its like forever living through a translator instead of just learning the language in the first instance, you add more points of potential failure.
- BoiledCabbage 8y ago
  Domain Drive Design is one of those things that seems so easy to write off as "just another process" but looking closer it seems like it really is a solid method for resolving issues of modeling, requirements, implementation and communicstion on a project. I expect to see is continue to organically grow in popularity as people try it and adopt it. It's both obvious and insightful at the same time.
- delusional 8y ago
  I recently read the red book, and I'm a little torn. The strategic patterns are great (I love the idea of bounded contexts, Ubiquitous languages, and integration), but the tactical patterns i'm less sure of. I'm not sure i like the idea of going through what's essentially a batch job to export my events inside one bounded context. I'm also not sure i like going through an external message bus to operate between aggregates. I don't have any better ideas, but i wonder if it's necessary to discard my reservations to succeed in the strategic goal.
zabil 8y ago
Shameless plug. We've built Gauge and Taiko to address this problem. Here the specifications are in Markdown and the API for automating the browser is user centric. It treats the browser like a black box. You can find more info https://gauge.org https://gauge.org https://taiko.gauge.org https://taiko.gauge.org

by neves 8y ago

pcm191 8y ago

Hi Neves Could not agree more. That's why Andy Pols and I recast the BA role as a Business Coach back in the day. Chris

endiangroup 8y ago

Thats where things like Domain Driven Design are going, and really it makes a lot of sense. Why express and model your domain in terms outside of it? Its like forever living through a translator instead of just learning the language in the first instance, you add more points of potential failure.

BoiledCabbage 8y ago
Domain Drive Design is one of those things that seems so easy to write off as "just another process" but looking closer it seems like it really is a solid method for resolving issues of modeling, requirements, implementation and communicstion on a project. I expect to see is continue to organically grow in popularity as people try it and adopt it. It's both obvious and insightful at the same time.
delusional 8y ago
I recently read the red book, and I'm a little torn. The strategic patterns are great (I love the idea of bounded contexts, Ubiquitous languages, and integration), but the tactical patterns i'm less sure of. I'm not sure i like the idea of going through what's essentially a batch job to export my events inside one bounded context. I'm also not sure i like going through an external message bus to operate between aggregates. I don't have any better ideas, but i wonder if it's necessary to discard my reservations to succeed in the strategic goal.

zabil 8y ago

Shameless plug. We've built Gauge and Taiko to address this problem. Here the specifications are in Markdown and the API for automating the browser is user centric. It treats the browser like a black box. You can find more info https://gauge.org https://gauge.org https://taiko.gauge.org https://taiko.gauge.org