We have a cohesive team of developers and domain experts so
the concept of DDD Bounded Contexts (and the analogys) is very clear to
us. What of the concept of IT Ops, perhaps it is a separate bounded context / business component? Perhaps its main function to support the composition of
a User Interface?
best regards -
Go a bit further with your question. What is the main problem or concern?
Udi’s point is that all code belongs to some Service.
So config files, startup.cs, sending bits to a 3rd party web service, composite ui orchestration/interfaces, etc all belong to IT/OPS. IT/OPS components will be found in every deployment.
What else?
Thanks - perhaps the question is about the team working on IT/OPS. Where within a service/bounded context/business component it is one team, one language. But IT/OPS - as a service/etc. - is something each team must share? IT/OPS is common “technical” parts of software. So each bounded context “team” shares resources with the a group that is there to serve the “config” et.al ??
We are looking to add an IT/OPS team member and I’m wrestling with how much this person could relieve the burden on our “BC” developers … some of it perhaps is dba work, build/deploys …
Do you have experience with an IT/OPS human resource “organization” and one you prefer ?
If this discussion needs to move off this topic … I’m sure the moderators will let me know 
You’re right. This is not heavily related to event-store.
I’ve always worked in situations where everyone has to where “hats” from multiple BCs.
That said, having an integrated team where an “ops” specialist is embedded with the developers has proven very successful. Lots of accidental innovation. I noticed that entire classes of production problems simply never happened because everyone was working on “making the software run in production”. Not “writing code” and “monitoring software”.
People call this devops now. And then they use devops to mean “we would like to hire people, but don’t want to actually change anything about how we run our organization, so we’ll use this label…and we’re agile too”.
Thanks again -