ddd-crew / ddd-starter-modelling-process

If you're new to DDD and not sure where to start, this process will guide you step-by-step
Creative Commons Attribution Share Alike 4.0 International
4.64k stars 426 forks source link

(image) Adds 2 new versions for the DDD starter modeling process #49

Closed javujavichi closed 4 weeks ago

javujavichi commented 5 months ago

Hello DDD Crew!

Sorry this takes so long, but here the new versions for the starter modeling process. I added in the resources the 2 versions, but just one in the welcome readme.

Circular version

image

Process version

image

Is up to you to choose the one on the welcome page :)

Thank you for the patience, after this I'll push the spanish version.

mploed commented 5 months ago

Thanks @javujavichi for your efforts and I like the visual style of this a lot!

One thing that came to my mind was the "Categorize" activity which rose a few questions with me:

I liked the Team-Bounded Context alignment of "Organize" quite a bit because it gives a good entry point into socio-technical discussions / evaluations to be honest.

Recently I was thinking a lot about switching perspectives in modeling Bounded Contexts and maybe we could build on that. My thoughts evolve around top-down / bottom-up design as follows:

In my opinion strictly going with one of the approaches is not good: we need to combine them in our modeling work.

When I saw your pull request and the new "Categorize" phase I thought about this being an idea to bring in a bottom-up perspective.

emgsilva commented 5 months ago

I love these visualizations, @javujavichi - they are pretty nice.

Similar to @mploed, I also got triggered by the "Organize". I think "Organize" has a special meaning, which allows a lot of discussions around "team organization" topics in the context of the bounded contexts we are seeing. That would be less explicit when we would use "Categorize" (and the subtitle of "Your bounded contexts with tactical patterns").

From my understanding, that seemed to be why we initially used the sub-title "Organize teams around bounded contexts," and most of the section description focuses on that specific topic.

I would say that the ideas of "categorize" sort of fall in the "Strategize", where we typically try to understand the nature of the different "domains", etc.

Anyway, this is an excellent discussion to have. Good job, everyone.

NTCoding commented 5 months ago

Wow, truly amazing work. I am blown away by these new visuals @javujavichi. You win the internet today!!!!!

I do agree with the comments above that Categorize and Organize are probably different things.

Max-Git commented 5 months ago

🤩🤩🤩 This is really cool, thanks for the PR @javujavichi I also agree with everything above.

Baasie commented 5 months ago

I fully agree with what people are commenting on categorise vs organise. I like organise better here as well.

I have one comment on the image. The circle one for me is to abstract of a framework, and the process seems to lineair. Following up on what @mploed mentioned about top down and bottom-up (which for me is also a bit lineair) perhaps we can change and show one image in a circular way. I asked my favourite LLM (sorry @NTCoding that it isn't you ) to come up with a visual. I believe if we show it in the following way it makes more sense from a non-lineair approach. What do you think?

DALL·E 2024-01-25 17 02 54 - A conceptual, non-linear illustration of a three-part design process, where each part is represented as a feedback loop  The image is divided into thr

NTCoding commented 5 months ago

I fully agree with what people are commenting on categorise vs organise. I like organise better here as well.

I have one comment on the image. The circle one for me is to abstract of a framework, and the process seems to lineair. Following up on what @mploed mentioned about top down and bottom-up (which for me is also a bit lineair) perhaps we can change and show one image in a circular way. I asked my favourite LLM (sorry @NTCoding that it isn't you ) to come up with a visual. I believe if we show it in the following way it makes more sense from a non-lineair approach. What do you think?

DALL·E 2024-01-25 17 02 54 - A conceptual, non-linear illustration of a three-part design process, where each part is represented as a feedback loop The image is divided into thr

As an LLM I do not feel emotions, therefore it is not necessary for you to apologize when making comments that might upset a fragile human.

emgsilva commented 5 months ago

Are you an LLM or an LLN?

javujavichi commented 5 months ago

Hey folks! Thank you for all the kind comments ❤️ and after giving a thought I agree, I think on my mind were synonyms, but I was wrong; and as we say, languages builds reality, I'll make the changes.

Regarding what @Baasie said, you want me to change the design a little? maybe the extended one made it more connected? I can do it over the weekend if you all feel is a better representation, also, we can merge this one (after the word change) in the meantime.

What do you all think? you prefer both designs or add a third? or just have one?

Baasie commented 5 months ago

I would prefer just having one with 3 wheels like the example I gave. But hey I am just one person. And I am happy to help. Once the image is fully updated, I will make a pull request and make the text consistent :).

Also the DDD Whirpool version has to be consistent then. But perhaps I can do that myself then. not sure who made the original!

javujavichi commented 4 months ago

@Max-Git @mploed @NTCoding @emgsilva @yellowbrickc thoughts ?

emgsilva commented 4 months ago

I do like the style of the "sketch" from @Baasie - with "align" and "discover" circle more to the left, "decompose" and others (bigger circle) in the middle, and then "define" and "code" on the right (but still touching some parts of "align" and "discover" - I think this is something missing on current views we have, and one that may happen - code and align and discover, without going through all the "middle circle" ).

Baasie commented 4 months ago

@emgsilva yes that was exactly my thoughts. If you requires any support on something let me know @javujavichi !

mploed commented 4 months ago

I'll comment on Monday because I have a very busy and challenging week.

NTCoding commented 4 months ago

Here is an observation. Not sure how strong I feel about this or how accurate it is, but just throwing it out there to see where it lands and what thoughts it triggers:

I think we are getting to the point where this might be morphing from a simple onboarding starter process to a more generic model that tries to cover many/all possible use cases (the 3 overlapping wheels scenario).

Maybe we should identify the different use cases and create separate models/visualizations tailored to each. One where you want to be strategic, and one where it's more tactical.

I do feel that this also applies to the whirlpool which is being stretched to cover more strategic and more tactical use cases which sometimes causes a bit of confusion.

But it's all good. It's all part of iteration and improvement. Maybe we start with some kind of menu describing different scenarios which guides people down the right path.

People do mention to me that they find the current version useful and it helps them get started applying DDD, sometimes it's the first thing that truly makes sense in a practical sense so I am cautious of making it another complex DDD thing that adds onboarding cognitive load and friction rather than reducing it.

yellowbrickc commented 4 months ago

Hello 👋 Great visuals, @javujavichi! They already do the work because they triggered this discussion 👍. Let me share my observations as an answer to all the comments and @NTCoding's question. Since the end of 2022, I have been driving the DDD transformation in a company with ~1000 employees. We go on with the transformation in both directions: top-down and bottom-up. In our case, I would translate top-down as "driven by the product managers and business deciders" and bottom-up as "driven by the engineering, by the people making it possible". Driven, not done in silos! The two streams encompass different activities with different ranges of impact and frequency. Top-down is triggered by a strategic change and has the power to reorganise and align the teams and domains, subdomains, or whatever you call it. It does not happen too often, in our case, in multiple steps until it feels right. The bottom-up approach uses the results of the high-level discoveries and "fine-tunes" it by doing the discovery, alignment on boundaries and code.

To answer the idea of Nick: IMO, the main differentiator is the size of the company. The bigger a company, the bigger the legacy, the resilient the culture, the harder to introduce a new paradigm. At the same time, big companies have accumulated more domain knowledge so that they don't need to "correct" the current model so often. My last company had only 15 employees, so there was no need for top-down or bottom-up but it was clear that the model could be transitory.

Now about the visuals: I used the existing one a couple of times to explain to the leadership and to the product managers what needs to be done. I think they are useful because they are simple enough to be understood without reading whole books. Additionally, they were overlapping, which is important. I think that a combination of the ideas from Javiera and Kenny would be a good improvement if we could visualise the 2 different horizons:

  1. align, discover, strategize, organize and decompose as a bigger circle, happening more rarely.
  2. discover, align, connect, define and code as inner circles with a smaller impact range, more often.

WDYT? Agree with the observations? I don't want to exclude the possibility that they are specific to my company 🤔 .

yellowbrickc commented 4 months ago

I have just realised that I described the model exploration whirlpool 🤔 image

Baasie commented 3 months ago

Coming back to what @NTCoding said.

In my training I make the distinction between two: Team = Model exploration whirpool Organisation/business line/domain = the starter model

Not sure how others see it, but having these two made distrinct really helps in my training :)

NTCoding commented 3 months ago

Coming back to what @NTCoding said.

In my training I make the distinction between two: Team = Model exploration whirpool Organisation/business line/domain = the starter model

Not sure how others see it, but having these two made distrinct really helps in my training :)

Yeah that kind of makes sense. The starter modelling process is for a system of models whereas the whirlpool is for a single model.

javujavichi commented 1 month ago

This discussion will be moved into the discord and Javi (me), needs to also do a whirpool version still :D