|
|
|
|
|
|
by supermatt
30 days ago
|
|
|
That’s great! But don’t fall into the trap that the graph is the ultimate representation of all. You will get a topology, but you often need more than topologies to understand the whole. Behaviour of the parts themselves is covered in the manifesto, and there is a companion that covers the connecting of the parts: https://shapeofthesystem.com/the-shape-of-the-whole |
|
|
Basically, when I was using my first version of Coherence to write down what system does on lowest level I found myself imagining in my head database records. And this is exhausting when you have more than 2 tables to think about.
And so I don't want to imagine them, I want DB records represented as entities I can simply render onto screen and look at them while I think how they should interact with each other.
Now, this is topology + domain modeling. Topology/semantics here is describing what happens with those domain models over time, what states they, how they transition, what attributes models might have, and most important — which code symbol describes all of that.
So for example, I am making Job Tracking System. I need to persist Job record. I visualize it as a row in table and I can model it without attaching to code. And then we can say:
- "this entity (job) --(has_attribute)--> status", or
- "job -(described_by)-> class JobRecord",
- "job -(observed_in)-> trace",
- "job -(verified_by)-> job_test.rb".
This gives us useful semantics / description / context / domain knowledge + links it to code + test that confirms model shape, or system state transition, or process, or product behavior.
And you can describe it at any level you want.
If you don't know the implementation details yet, a greenfield project? Well, just start with Product level specs, high level description what users will see.
Is it brown-field legacy monolith 500k LoC? Well, just reverse-engineer intent from code (I even have guide how to do this and I did it on 10k LoC successfully), then align people on that "intent graph", and then connect it into CI/CD so that it becomes default review artifact on EVERY single pull request.
And the key here is to isolate context around domain model we're interested in. Make it minimal but useful to make decisions. And make it easy to pull more [relevant] context, or remove [unnecessary] context.
I still don’t fully know how to avoid tunnel vision once you have only one slice of the graph and models in front of you. E.g. failure mode might be somewhere not even described by a link or something exists entirely outside of the graph.
This would be the next thing to solve.
And meanwhile I'd like to thank you for showing me this problem.