yellowbrickc

Notizen

• type definition: Skalare Werte: int, float, string, bool, ID (int oder string)

• Änderungen in der Schnittstelle: nur Erweiterungen, alte Felder deprecated markieren

• Pflichtfelder mit ! am Ende des Feldes in der Definition

• Request/Response Zyklus

  • Responses: immer Code 200, Error in error-objekt

Queries:

yellowbrickc

Scenario: different business teams building parts of a product, splitted by business domains. We are anly communicate via domain events published to a message bus and sometimes via published links.
As the domain events are the "contracts" between the business domains we want to declare and enforce the schemas of the events. 
Our solution is built in node but the concept could work in any stack.

yellowbrickc

Why this gist? As answer to https://twitter.com/dcarral/status/1231730478002135040

Disclaimer: my experience is based on smaller dev teams, up to 25 people. I never worked with a few hundred devs, I cannot say how my way would work out in such a setup.

I agree and like very much the explanations and tipps which Dylan gave. But:

• I would never go for sepparated teams for backend and frontend.
• I would not consider an architect OUTSIDE of a team. We agree that architects must code and I think, there aren't any reasons that they are not part of the team, as devs with a special role. I have this role for years now and I develop features like everybody else in team but also have the responsibility to plan and design and CHALLENGE the architecture. The time spent for these tasks is time invested in product development, in features. Also why not working in a team? If I didn't had time for tasks, I discussed it with my team and they didn't relied on my presence. If I started tasks but didn't had time to finished

yellowbrickc

The idea

I see 2 layers, which should fit very well: a technical and a human component. DDD (the book, the theory i.e.) focuses mostly on the technical one but the whole transformation or product can fail if the human component is ignored or not focused enough.

I have some hints and hope to collect together with you a lot of others. The goal would be to have a list at the end which can be used as a guide for how to decide about BC boundaries when both aspects are taken into account. My other goal would be to find out, what can go wrong when the boundaries are wrongly chosen and how high would be the costs?

Question 1 for @Marco or @Kenny: are you moderating?
Question 2: what do you think about a "whiteboard", to visualize this list?

Signs on the value stream:

• feature branches: why are they needed? how often they block other features? how often they lead to merge conflicts?