[Draft] Proposal

[NTCoding]

A constant challenge when describing domain-driven architecture is a lack of established naming and a lot of ambiguity.

Team Topologies has shown the benefits to have standardised names for team structures. I think the same is true for for other domain-related architectural concepts. This PR is a very rough draft of my very first attempt at creating a very first version of this very difficult challenge.

All feedback, criticisms, alternative suggestions, and links to existing or similar works is welcomed and appreciated.

[emgsilva]

Hey @NTCoding - great stuff! I think this "harmonization" can help a lot on providing language for our discussions on these topics (there is a lot of different variations/interpretations...)!

I will do a more in-depth review coming days, but two things that immediately jump into my eye on a quick scan:

• 1: I can see the reasoning of a Product having "User Journeys", that is unquestionable (and BTW, user journey can be UI or API or whatever the customer uses to interact). However, I am not yet 100% convinced about the strict separation of Products and "Domains"/"Sub-Domains": this can be true in some cases and situations, but I don't think we should generalize. I think there will be situations (if not most of the time) where the user journeys and domains/sub-domains form the Product (or value streams within the product). This is a bit the scenario also where your "organizational setup" matches that pattern, like the very last image you have (Some teams may own a mixture of user journeys and subdomains.). Maybe we should make that clear on the Product definition (and diagrams at the start)... I will think a bit further on this (this is also something I am discussing at the moment in my own org).
• 2: the image of the "Some teams may be focused on providing information and services, responsible for only subdomains."... It is "blue" as in being a "Platform Teams", while all the others are "SATs" (yellow). I would keep that consistent and use SAT (yellow) also for this case.

Cheers!

[Baasie]

Hi @NTCoding

1. I like the initial draft. Also what @emgsilva said is valuable, User journeys are UI or API in this case.

2. I would also like to think that product and domain are not exclusively separated. I think we had a similar discussion with @yellowbrickc. Isn't it so that a product can contain A user journey and a domain together? I know a product or user journey can have several Domains, seen that a lot.

3. In your first pictures I like the separation of Domain that has sub-domain. but later on, you removed the domain entirely. Perhaps it is nice to also show it there or:

4. I was in paul Rayner his workshop and he explained it a bit like 30000 feet 10000 feet and 0. In my head it might look like this for this example:
   

My first thought, I need to think a bit more about it this afternoon :)

[NTCoding]

@emgsilva @Baasie

I understand your perspective on the products vs journeys vs subdomains. My reasoning for keeping user journeys and subdomains separate in this model are the following:

1. Most subdomains (IME) are consumed by multiple user journeys in multiple products (desktop app, iOS app, Android app, ioT app, internal admin app etc)

2. Most user journeys (IME) combine data and capabilities from multiple subdomains

3. Even when there is a 1:1 mapping between product, journey, subdomain (often in a startup or new product), there is still the potential for the subdomain to be consumed by multiple apps in the future (and often they do IME).

4. My current thinking is that a user journey is a way to expose domain information and capabilities, and it's more of an organisational structure to bundle journeys and subdomains together

So to summarise: this proposed model captures the most common scenarios that I experience. I didn't try to create a generic model that catches edge cases. I would rather call out the edge cases as separate patterns. However, these may not be edge cases to other people and we should instead create a better model.

I think the following where there is just 1 product with 1 journey and 1 subdomain is a bit of an edge case. I don't know if I have actually seen this. Maybe it aligns with Self-Contained Systems (https://scs-architecture.org/). I call it here a single product system.

It's going to take a while and some discussion to get this model right and there is no rush, so we can keep the discussion going for as long as needed.

[NTCoding]

@emgsilva

"I would keep that consistent and use SAT (yellow) also for this case."

Yes, this is a good idea thanks.

@Baasie

In your first pictures I like the separation of Domain that has sub-domain. but later on, you removed the domain entirely.

In that example I wanted to show that a user journey could interact with multiple subdomains but they might not all be from the same domain.

• The different levels is a good idea. That's what I've implicitly done but it's good to call it out clearly.

It feels like a high-level overview and then a patterns section and also some real world examples should be added to this proposal.

[Max-Git]

Sorry for the dumb question but could you provide me with examples where User Journeys cross multiple Domains within the same Organization? I can easily think of scenarios where the User Journey crosses multiple Sub-Domains but I'm all ears for scenerios with multiple domains. Wouldn't the Domain be the highest level for one organization?

[NTCoding]

Hi @Max-Git

Very good question. I was waiting for the first person to raise this issue. I have been intentionally bold and provocative here.

Is there a 1:1 mapping between an organisation and a domain. I.e. is an entire company just 1 domain?

There are a few reasons why I don't this is the case:

1. In most organisations, there are many clusters of subdomains which all relately closely around a key theme and are owned by groups of teams who work closely together (aka tribes in Spotify Model terminology). We need a word to describe these

2. Many clients I've worked with have already adopted this convention. They talk about "domains" rather than domain. So my assumption is it's either more intuitive or pervasive, but why fight common convention with a competing definition? If there is a good reason for a 1:1 between org and domain I would be happy to get behind it.

3. This also fits with Uber's description of a domain

Domains
Uber domains represent a collection of one or more microservices tied to a logical grouping of functionality. A common question in designing a domain is “how big should a domain be?” We give no guidance here. Some domains can include tens of services, some domains only a single service. The important task is to think carefully about the logical role of each collection. For instance, our map search services constitute a domain, fare services are a domain, matching platform (matching riders and drivers) are a domain. These also don’t always follow company org structure. The Uber Maps org itself is split into three domains, with 80 microservices behind 3 different gateways.

So my overall feeling is that we should go with the consensus, even if that was not the original intention of a domain in DDD. If the goal is to have a common language in the industry I think it makes sense to be a little flexible in order to fit into the bigger picture.

[NTCoding]

Hey @Max-Git

Regarding examples, here's one I've been using for a couple of years form Org Design for Design Orgs

We could consider growth, seller tools, and reviews as belonging to 3 different domains.

There are other interesting points here:

• Experience instead of products
• An experience is a different concept to a product: an Experience could exist across multiple product. The buyer experience on the mobile product and the buyer experience on the desktop product. Or maybe Mobile Buyer Experience and Desktop Buyer Experience are different kinds of experience and product is irrelevant
• Some subdomains are involved in multiple different user journeys for different users whereas some are focused on just 1 user
• The cognitive load is too high for 1 team to own subdomains and be responsible for an end-to-end user journey

[Max-Git]

Thanks for your answer @NTCoding .
I'm now kinda thinking out loud but what about keeping Domain at the top level with a 1:1 between org and domain and have something like : Domain->Sub Domains->Business Capabilities->Bounded Contexts.
But maybe there's also a 1:1 betweeen Sub Domains and Business Capabilities. 🤔
I don't know if all this makes sense actually :)

[Baasie]

nice dialogue!

From my experience, big companies have several domains. For instance, a bank might have a finance domain, mortgage, payment. And really these are big domains that each have their own sub-domains. So that is what in my mind is the 30000 feet.

Now in these enterprises, we have seen that there are business process and customer journeys over these domains. You can argue if the domain are actually correct, but I have seen it.

So coming back what you said @NTCoding and with @Max-Git said I came up with the following adjustments that show from 30000 feat -> 10000 feat to a team level. Were the naming might change for something right, but perhaps the mapping stays the same.

What do you think?

[yellowbrickc]

What a good discussion in such a short time! I see a long "virtual session" happening here 😄
Here my first thoughts:

1. I like the introduction of the notion "user journey" so early. Do I get it right and you mean with the user journey not the UI of something but the user experience @NTCoding ? (things can happen in the background and I can get be involved or the experience is NOT to be involved) This is how I would interpret the user journey = the whole experience with this product I pay for
2. I agree with @Max-Git , I never saw a product consisting of 2 products. I think this would be a real edge case, what we didn't want to discuss yet.
   Why I think that product and domain have a 1:1 relationship: as I learned it the hard way, most companies have one real goal, real value proposition. uber describes it's domains by the number of microservices (I think, this is BS, it is an implementation detail) but in the reality, they sell one service, one user experience. I would consider the map service a subdomain as long as it is not sold as "uber's maps". The other reason is the dynamic of most organisations: to have a successful product you need commitment, ownership and collaboration (etc). Would this work out when the same departments work for different products? Or the 2 (imaginary) products would be actually one with one goal, maybe for different types of users. Most companies are really good in exactly one thing and this is what they want to sell.

Now @Baasie you say finance, mortgage, payment are different domains. Are they really? Or are they just modelled that way?

[Hyunk3l]

Is there a 1:1 mapping between an organisation and a domain. I.e. is an entire company just 1 domain?

@NTCoding
I'd say yes in most of the cases. In the concrete case of Uber, in my understanding, they have different domains:

• private taxis domain (uber * fleet?)
• food & goods delivery
  but since is the same company, they may share some subdomains, like finance for instance.

From my experience, big companies have several domains. For instance, a bank might have a finance domain, mortgage, payment. And really these are big domains that each have their own sub-domains. So that is what in my mind is the 30000 feet.

@Baasie
Imo banks have one domain: Banking. Then within it, there are multiple subdomains: lending, finance, payments, cards etc.

[Baasie]

Hi @Hyunk3l ,

The way I see it domains are in the problem space. I worked at many enterprises and seeing the bank as one domain is too big and does not match their org structure, which is already split into several entities with there own PNL. As an example I worked at insurance and pension company, they said our core business is pensions, but actually, the money came from pensions and their profit came from asset management side which in organisation matter was a different entity. But that asset management also got half of their money to invest from many from private investors. So you had several domains in the enterprise, pension, insurance and asset management (and perhaps even more). They themselves talked about it that way as well. And all these domains would have sub-domains with a core problem.

That is how I match an enterprise company to domains to sub-domains. Of course for smaller companies, this doesn't match.

Another way of looking at it (and not an expert here in capability modelling) is from @trondhjort his capability modelling talk

That for me would resolve in:
30000 feet: Enterprise -> Domains
10000 feet: Domains -> subdomains
Team level -> Subdomains to bounded contexts

@NTCoding I like your picture of the experience. For me, product and experience is still ambiguous and different for most companies and it will definitely help for DDD'ers to make some common ground here. I need to think about it more, but I like your picture. Another thing still on my mind is you have the user journey but also the business process. How do we map that? A business process can run over several domains as well, for instance, the payment lifecycle in a bank might do that.

[Baasie]

So was rereading something from @NTCoding and @Max-Git about Domain to a product, and I agree there. While discussing with Paul de Raaij (a colleague, he will also join the conversation now) and mapped it now like the following:

[NTCoding]

Hey everyone,

A lot of great discussion here. Thank you for all of the input so far. Every contribution is valuable and enhances the discussion. At some point we need to come to agreement, but for now let's just keep discussing ideas and different perspectives. There is no need to rush this.

So, I'd like to make observations and reply to a few comments.

1. The concept of a "domain" is ambiguous and recursive. In DDD, we have a way of dealing with this... bounded contexts. So we need to apply DDD thinking to this problem and define what we mean by these terms in the context of DDD

Choosing domain boundaries is subjective. The dictionary definition is extremely vague. There is no little constraint on the size, scope, or nature of a domain:

2. We can also see that domains are infinitely hierarchical. For any given domain, we could focus on just a subset of that domain and consider it a domain in its own right.

So what's the definition of a domain in DDD? How do we create a useful, working definition that's flexible but not vague and confusing like we have now?

Perhaps we can use the business capabilities model, having levels of capabilities. Or perhaps we can define our own model: micro domains, macro domains, organisation domains?

Looking forward to your thoughts.

.

[NTCoding]

@Baasie How would the domain of Identity fit into your new model where each product is limited to a single domain?

In most organisations, there are domains like Identity which are used by all or may of a company's products.

[NTCoding]

@Baasie great questions:

@NTCoding I like your picture of the experience. For me, product and experience is still ambiguous and different for most companies and it will definitely help for DDD'ers to make some common ground here. I need to think about it more, but I like your picture.

I'm trying not to invent the wheel here. I'm currently researching if there is an existing model of "product architecture" we can use. Some of the product building blocks are:

• User journey
• User flow
• User task
• User Experience (as in a concrete experience, not the discipline of UX)
• Capability / feature

The concept of a product, like domain, is also hierarchical. For Amazon.com, there may be product managers who treat the home page, the details page, the personalisation etc as separate products.

Another thing still on my mind is you have the user journey but also the business process. How do we map that? A business process can run over several domains as well, for instance, the payment lifecycle in a bank might do that.

A business process feels easier to define and more intuitive (thought it could be false confidence). It's a series of steps governed by rules. Some steps may be carried out by a user, and some steps may be automated in software. A business process can be small within a single subdomain or large spanning many subdomains.

[Baasie]

Another thing that is on my mind is that with Context Mapping, and this was a discussion with Paul Rayner, is that you map the solution space, the bounded contexts as-is. Now with Big Picture EventStorming you map the problem space as-is and model the (sub)domains and the bounded context that you would (to-be perhaps).

But the as-is context map can be a mismatch with your as-is big picture eventstorming to domains.

[Baasie]

Going back to Indy her picture and what @NTCoding said. I guess Big Picture EventStorming at the start (Chaotic exploration) is the problem space. But as soon as you start enforcing the timeline you are designing as what @NTCoding said, so that IS the solution space, that is participatory design as you see in the picture which makes sense. In Anthropology they call it Emic and Ethic, and with qualitative research, you listen and observe and state what is there. As soon as you make a judgement about something, or design you go to the Ethic side. Now again this is my novel knowledge of Anthropology but it matches with what Indy said:

[Max-Git]

Wow, there’s a lot of interesting things to read here, thanks everyone for sharing their views and thoughts!

Concerning Problem Space vs Solution Space, I’d rather go with something similar to what @yellowbrickc described above and put only the “why” in the Problem Space. I agree that “Why do you want this?” is the key question to ask when you want to bring the conversation back to the Problem Space.
As @NTCoding said, “there are an infinite number of ways to model a solution” so if I look at an Impact Map, everything at the right of the “why” (the Business Goal), are assumptions, bets, options about “who”, “how” and “what” could help to reach that goal. All those options belong to the Solution Space.
From my point of view, when doing a Big Picture Event Storming, the chaotic exploration part is definitely in the Problem Space. Stickies are facts that describe the problem. But as soon as you want to map those events to specific Bounded Context, you’re making bets and you’re already in the Solution Space. In a Design Level Event Storming, if you call your business rules and invariants “Aggregates”, you’re also in the Solution Space because you think that the solution to enforce those invariants is to implement an Aggregate.

Now for what you @NTCoding are trying to achieve I have the feeling that it might end-up in a new terminology that does not belong to the DDD lingo.
In one of the videos @Baasie mentioned (https://www.youtube.com/watch?v=wF0OHhVELyo) Eric is explaining something that looks similar to what we’re doing right now. He’s saying that when people from 2 different sub-domains are trying to speak together, they do not understand each other until they find out a third jargon. And from this new terminology a new sub-domain emerges.
Bringing terminology from DDD, User Experience, Enterprise Architecture, Capability Management, Mathematics and even Anthropology might end up in a new sub-domain with a new ubiquitous language!

[yellowbrickc]

Good catch @Max-Git 😆 Maybe we do - and is this bad? I stopped for long to think about DDD as something restrained to architecture, software design or IT questions. (just think about the socio-technical movement which finally becomes acknowledged). IMO the one common goal "understand and solve problems of your (possible) customers" needs a Ubiquitous Langauge, needs a structure, needs the whole company, often needs all terms you mentioned. This does not mean that we forgot about our goal to define DDD terminologies but nobody said that we cannot use our knowledge from other areas 😉 (so that we do not reinvent the wheel)

@NTCoding I think your description is perfect.

Problem space: user needs
Existing solution space: current business processes
Proposed solution space: how we will solve the user needs (may modify existing solution space or live outside of it)

The currently existing solution space was created as the answer to some problems. At the same time with every new problem, our current solutions could (and often do) become a problem. But still if we talk about the problem they cause we don't talk about BCs but maybe about the current organisation or skills, i.e. Our current solutions will always belong to the right side and implicitly create a pendant on the left side "continue to solve the earlier problems too".

What I want to say: I don't think that we will need to take the current solutions in the discussion, they won't change the definition: a need forms the problem space

        I want to fill in my tax return documents (the example from the article)

and our response to it, whatever it would be (described in Impact Mapping too, like @Max-Git said)

        take a pen and paper or buy a tool or ...

forms the solution space.

I spent the afternoon watching a talk from Jabe and discussing with him and a few others about flows and turbulences so I didn't watch the videos suggested by @Baasie yet. I would say, subdomains are organisational decisions too but still they would be part of the solution space and not of the problem space (just like you said @NTCoding ). We don't want to play games with Conway's Law 😉 I saw it very often: problems are not solvable until the companies reorganise to make it possible. And how they reorganize is only a bet, just like the boundaries in DDD.

[yellowbrickc]

Regarding the question from @Baasie

Perhaps we should take this discussion online in a two-hour VDDD exploration and co-creation of this common ground. Who would be up for it?

I am sure that at one point it will be better to meet and discuss directly. I am not sure, that we are already there. But maybe we could start to plan it, like date and time? What do you think about the idea to make it a ddd-crew meeting, not a normal public session so that we can focus on this one goal?

[skleanthous]

Hey all, sorry for earlier; I made a commitment for weekends to be family time, and I'm doing my best to keep it.

While I see the discussion moved, as promised, I'll expand a bit on how I think the mathematical definitions can apply in product development (and imho in a natural way), just in case this is useful. Personally, and as I said above, I don't necessarily think that we need to adhere to this definition, but it may provide some value.

TL;DR: Domains and subdomains, and how they work, along with their rules and anything that can happen within a domain, defines the problem space. Operating systems and models (regardless of how high-level or abstracted) that we confirm that it would meet the requirements (even if they're suboptimal) are in solution space.

As I said above in math, there are three things:

1. A problem definition: This would be what we're trying to solve, the equations or criteria for which we need to find values that meet them.
2. The problem space: this is the mathematical space or sets of numbers which we are working on; think positive integers, or the 2-dimensional space of (x,y).
3. The solution space: the subset of the problem space which meets the criteria defined in the problem definition

These naturally correspond to the problems we have in product development as:

1. The problem definition: The customer needs, the company mission statement, the product vision, etc.
2. The problem space: the domains and subdomains, and their rules, that meet those customer needs. The problem space is in fact defined by anything (any system and\or processes) that is legal under the rules of these domains, and these determine how things work, regardless if these would be good for our product or not (this relates to the mathematical definition of problem space like "all real numbers"). Semantic groups of functions or capabilities also belong in the problem space. For example, the billings department may be able to do much more than reconcile invoices, even if that's all they need to do.
3. The solutions space: contains the subset of all possible systems and processes from the problem space that meet the requirements that we have. A model of a system that is in the solutions space is a model in the solution space. Continuing the above example, several invoice reconciliation processes may meet our requirements and are in the solutions space. Other invoice reconciliation processes may exist (and maybe followed in other companies), but if they do not meet the user\product\business requirements, they only belong to the problem space.

It follows from the above that there is a clear separation from the above definition:

• Everything that meets the rules of the domain (not necessarily the requirements we have from our product) belongs to the problem space
• If one model or system meets the rules of the domain (i.e. exists in the problem space) is confirmed to meet our requirements, it is then identified to also belong in the solution space (regardless of the level of abstraction).
• Requirement extraction doesn't form part of the problem space, it's simply understanding the problem as defined.

It is a corollary to the above that tools don't necessarily belong to one of the spaces. Tools may be more useful for some activity (like brainstorming or requirement extraction) and can help us discover the problem space and\or identify if something is in the solutions space or not. Still, it's not tools that belong to particular spaces; it's systems and models. Semantic groups (like domains) are problem space by definition (as they contain more than just the specific solution space).

Anyway. The above is the definition as I understand it, and as I said, I'm not trying to force the above, just providing it in case someone sees value in it.

[skleanthous]

Also, earlier I wrote:

Having said the above, after my research I just tend to avoid using the terms problem space and solution space. I found little benefit in them

And I stand by that. I find using these terms (referring specifically and exclusively about solution space and problem space) to be an exercise in taxonomy. The problems I experienced are:

1. Misunderstanding/miscommunication. People do not understand the same thing (as it's evident from the above discussion) because we lack a clear and precise definition. I think this is and will continue to be a big problem. These terms have been in use for many years, and no-one (to my knowledge) challenged their "ubiquitousness", seemingly everyone implicitly thinking that everyone else had the same thing in mind. Introducing a definition now will not fix this because -if the past is any indication- people will not seek out a definition, nor proactively try to confirm their understanding of this term when they hear it. This behaviour in people will cause miscommunication to continue to exist.
2. Restricting the use of tools. I regularly hear "X is a [problem|solution] space tool". I think tools may find use outside of what we expect them to, and people hearing that a particular tool only works in one space may be negatively impacting the value we could derive from it. Note that I agree that some tools are indeed more useful in one space than the other.
3. Very unfortunate combinations of the above 😐
4. There is very little value to be gained by this categorization. After going through the journey to find out a definition of problem and solution space, I tried to think how does this help me. And honestly, the best reason I could find was that people were using these terms, and I was not sure I understood the right thing. I didn't find these were needed for communication or provided any practical benefit.
5. There are already much better ways to communicate, without these terms. We can directly express the desire, intent, customer needs, the rules of the domain, whatever, in more detail and accuracy.

That's not to say that I don't think there is any value in this, but I do believe we are overusing these terms, and they are problematic.

And to your question @yellowbrickc, I do ask people those things, but I very rarely use the terms solutions space or problem space anymore. I'm trying to be explicit: I'll ask people to brainstorm ideas, to focus on understanding the requirements, try to ignore or focus on solutions, etc.

[NTCoding]

Lots of good discussion here. @Baasie @yellowbrickc I agree that establishing common ground would be useful and VDDD is a great vehicle for that. Perhaps the purpose of the meetup should be to clearly define problem and solution space in the context of DDD or to decide that it is too ambiguous and avoid it (as per @skleanthous).

For me to be comfortable with a definition it needs to determine which space(s) the following belong to:

• A unmet user need
• A met user need
• An existing user journey
• An existing business process
• Proposed modifications to an existing business process
• A brand new business process
• A domain
• A subdomain

As a side topic, I'd also like to touch on the concept of "fuzziness" in DDD which a number of DDD practitioners refer to. I think fuzziness is a good thing when we all have shared understanding (aka common ground) on what is fuzzy about a specific concept. But when words are undefined, highly ambiguous and every DDD expert has a different definition, I find it to be unhelpful for everyone involved (unless we want DDD to look mysterious and complex for those on the outside and newcomers?).

Uber have put together a very clear definition of a domain in their context which is easy for people to understand and follow (https://eng.uber.com/microservice-architecture/). They provide a definition along with concrete examples.

[yellowbrickc]

This article from Uber is very good 👍 I miss some information about the organisation though. The only hint was the half-sentence about Uber Maps Org. At the same time, they say that this org split into three domains. => no 1:1 mapping between domains and organisation.
How I see it they use the DDD terminology only for the solution space. Maybe we should consider this way too. I am convinced that DDD cannot be applied successfully if it is considered a "tech-thing". But this does not mean that we must care about every involved person, we just need a good explanation of our terminology and our needs to be able to apply the DDD principles. The former is the goal of this repo here. The latter can follow later.
In that case I would see your question @NTCoding as follows:

• A unmet user need => a problem to solve
• A met user need => a problem solved earlier + a problem solved in the future too
• An existing user journey => a solution
• An existing business process => a solution
• Proposed modifications to an existing business process => a proposed solution
• A brand new business process => a proposed solution
• A domain => a (proposed) solution with implications to the organisation
• A subdomain => a proposed solution

Here also my suggestion: what about looking and discussing these terms from the perspective of the solution space, as (eventually part of) the answer to a problem?

[Baasie]

I read the article by Uber @NTCoding. And they created their own common ground internally is what I would call it. Coming back to what you said about the fuzziness, it reminds me of how EventStorming concept keep it to a minimal common ground in order to come up with a context-specific common ground together, a legend. I think that is the power, especially in design.

We talked about it a bit in person @NTCoding, and for me, designing should keep it to a minimal common ground to be able to explore. Else DDD design approach would take the course of what happened with BDD, it is now mostly given when then. BDD explore phase is about design, is about exploring to find common ground. Once that is set we can formalise it, perhaps in BDD.

We got to be careful that we don't do similar stuff to DDD, as to create to much structure for people and that becomes DDD. I know this is a polarisation between chaos vs structure and in my believe this is the balance we should be discussing and create a minimal concept for that structure. For me, we should give people heuristics to deal with the chaos, just enough so that design isn't too fixated on the outcome towards the structure set, just like EventStorming does IMO.

About the Problem vs Solution space. I think I do not agree with the notion of user needs == problem space. Now what Indi Young his picture represent let me started to rethink things, and I am not there yet, but here is some brainfart I got up to now:

User need is already a solution. Example: the need to reserve seats in the cinema, that need is a solution and not the purpose. If we go deeper on that, the purpose might be I want to see a movie on a big screen and sit comfortably together with my partner (guessing here, not quite there yet). That is the purpose for the customer, that is the problem space. The purpose of the cinema is to maxima revenue while still giving that purpose to the customer. If we take that back to domains and subdomains, I believe they can be problem space, if we do not focus on needs, but on purposes, and purpose resides in the language. Now again I am not there yet and need to think about it a bit more, perhaps in a session discussing it together :)

[NTCoding]

@yellowbrickc

How I see it they use the DDD terminology only for the solution space.

I think Uber uses a domain (what DDD might also call a subdomain) in the problem and solution space. From their article:

our map search services constitute a domain, fare services are a domain, matching platform (matching riders and drivers) are a domain.

I would expect map search and fares service have both unmet user needs (problem space) and existing microservices (solution space).

we just need a good explanation of our terminology and our needs to be able to apply the DDD principles

Uber is applying the principles of Domain-Driven Design: they have defined a ubiquitous language with a definition of key terms like domain that applies in their context. DDD currently doesn't have a Ubiquitous Language of its own (you could say Uber is doing DDD better than DDD).

[NTCoding]

@Baasie

I read the article by Uber @NTCoding. And they created their own common ground internally is what I would call it

Yeah, Uber has created a Ubiquitous Language in the bounded context of Uber which contains their definition of domain which is clear and with examples. They are applying DDD (arguably better than DDD is).

Coming back to what you said about the fuzziness, it reminds me of how EventStorming concept keep it to a minimal common ground in order to come up with a context-specific common ground together, a legend. I think that is the power, especially in design.

This is a very good example. EventStorming is fuzzy by design with a clear definition. DDD is fuzzy, largely unintentionally, because we all interpret the words to mean different things i.e. EventStorming has common ground DDD doesn't.

As an example, if you took 10 experienced EventStorming practitioners and asked them to explain what an EventStorm is and what a domain event is, I think you'd get answers which look very similar. As this thread has shown, when a group of DDD practitioners try to explain problem/solution space, domain, subdomain, we have very different opinions so we don't have enough common ground.

We got to be careful that we don't do similar stuff to BDD, as to create to much structure for people and that becomes DDD.

BDD is a good example of where people lost sight of the principles and got stuck on the practices. This has already happened to DDD with the tactical patterns.

Maybe one of the reasons DDD got associated with tactical patterns is because people couldn't related to domains, subdomains, problem/solution space because nobody understood what they meant. Whereas Entities, Value Objects, and Aggregates have very clear definitions with examples.

I don't believe we're adding any additional structure here. I believe we're trying establish common ground - creating a shared understanding of existing structures, the words we already use.

Going back to EventStorming, there is a lot of structure in EventStorming which has emerged: Big Picture, Process Modelling, Design Level, Swim lanes, Pivotal Events. These things are fuzzy in that they can be used flexibly. The might be a littley fuzzy in definition, but we have enough common ground on these structures that we can talk about and know wheat each person means.

Now again I am not there yet and need to think about it a bit more, perhaps in a session discussing it together :)

I'm with you :) I have my definition of problem space, solution space, domain, and subdomain but I'm happy to give it up so that I can have common ground with other DDD practitioners.

[yellowbrickc]

@NTCoding

I would expect map search and fares service have both unmet user needs (problem space) and existing microservices (solution space).

Maybe, they didn't write about it (this was the part I've missed).

After reading what @Baasie wrote I agree: we should keep it to a minimal common ground

I think this won't be hard to achieve as we obviously have different ideas about almost everything 😆 (For example I would describe a user need as "user want's to see a film" and not "user needs a seat". This would be the next logical step bc no user wants to stand for 2 hours or bc this is how cinemas work. IMO it is still part of the problem description and not part of the solution. There aren't many variations for this, one has to sit down.).

I just reread the initial definitions in the PR and I had the feeling that for now is quite opinionated. It relies very much on subdomains - which can exist or not. If I have one small company with one small team handling the one product the terminology "subdomain" would only add an over-head and no benefits. I would always prefer Bounded Contexts over sub-domains.

@NTCoding says:

I have my definition of problem space, solution space, domain, and subdomain but I'm happy to give it up so that I can have common ground with other DDD practitioners.

What do you (all) think about preparing our definition for the terms listed by Nick and to meet to find that minimal common ground?

This way we have all point of views in one place and make sure to keep enough fuzziness but still give valuable content. I mean something like this as a possible outcome:

Domains are composed of one or more subdomains, if subdomains are defined. Or in the case of smaller companies, the domain could include one or all bounded contexts.

[NTCoding]

@yellowbrickc I fear 1 sentence alone might be a bit too vague and still open to excessive interpretation. Uber provide examples and constraints and make fuzziness explicit in the clear definition of a concept (e.g. regarding how big a domain can be).

Eric also uses slightly longer definitions in his DDD reference book:

On a side note, according to this definition of a Core Domain:

• A core domain is solution space (it could also be problem space we don't know from this)
• A solution space can contain multiple domains
• A core domain is also synonymous with a subdomain (core/generic domain and core/generic subdomain are synonymous in the big blue book I believe).

[skleanthous]

Hey all. I believe we should do anything to remove ambiguity in communication.

In my opinion and experience, ambiguity within language, instructions and context is always bad, while ambiguity in goals helps in some cases (although I'd prefer to consider the goal-setting as being broad vs ambiguous), and I won't comment on ambiguity on other areas. Brainstorming (for example) is an exercise where we do not want to restrict anything, but it can be very damaging when the language we use is ambiguous, and people understand different things. The whole point of emphasizing language in DDD is to make sure we all understand the same thing, and a lot of the exercises we have has the exact purpose of removing ambiguity.

Regarding the above, think of this:

1. A game with vague, very difficult to understand rules
2. A game with very few, but clear rules
3. A game with a lot, but very clear rules

Game 2 would be something easy to pick up and allows for a lot of freedom. Game 3 will need people to read up on it, but they will be able to follow the instructions easily, and everybody who makes the effort will be able to participate. In game 1, there will be conflict; some players would disagree with others on basic premises and won't be able to proceed meaningfully until they have come up with their own unambiguous interpretations. This would be a delay, the end-result may be different than the designer intended, and people who agreed to one set of unambiguous instructions would not be able to play with people who have a different interpretation. Imo, 2 is good, 3 is useful in some specific cases, while 1 is never a good option.

Also, I would urge you to consider that you all here are leaders in the same community, and you all speak regularly to each other. We all know that within the same team (people who work closely together or mob for prolonged periods of time) there are rarely ambiguities (and they're small if there are any), but big ambiguities regularly exist across teams. By communicating regularly with each other, you're keeping the level of ambiguity in the terms we've discussed above quite low (even though it exists). This, however, may not be the case when other people are involved. When people are just starting to learn about DDD, what they misunderstand may be a lot, and from experience, this is one of the biggest impediments for adoption.

[NTCoding]

Hey @skleanthous.

I like your analogy about the games and your closing remark "this is one of the biggest impediments for adoption.". Over the course of this year, I have been thinking about how to improve the first-time user experience of DDD so that we can be a more open and inclusive community attracting diverse talents. I also see that the perception of DDD as being esoteric turns people away.

I was just reading some Simon Wardley and he argues that a common language is necessary for communication. It also reminds me of the DDD principle: Make the Implicit Explicit. It seems there are lots of implicit concepts in DDD: domains, subdomains, problem space and if we follow DDD principles we should make them explicit (not change their definition, just make it clear).

Regarding your game analogy, I think my perspective is that I don't want to change the rules of DDD, or remove any rules (or add any rules) I just want to make the difficult rules to understand clear. I feel (strategic) DDD is currently like game 1 but it should be game 2 (few rules, very flexible, but clear/explicit rules).

[skleanthous]

Yes, I think we are in agreement @NTCoding

I do agree we need to take DDD out of case 1. I don't know if as a whole it'll end up being a 2 or 3, but either would be a big improvement. I think basics of DDD should be made a 2 though, and accept some aspects could be a 3 and but useful in some "advanced" cases.

[NTCoding]

I just remembered Jeff Patton's way of explaining effective communication:

A word/phrase can have a fuzzy definition but that is orthogonal to the sender and receiver having the same shared understanding. The fuzziness is an explicit part of the word's definition not in the shared understanding.

[benvand]

Super interesting, beneficial discussion for the community and beyond.

I'd like to propose extending the Strategic Domain Driven Design definition of a domain/ sub-domain to explicitly recognise 'incentive'.
'Incentive' has a clear dictionary definition so is not creating ambiguity.

I think this is close to what @vladikk is getting at with use-cases(? do correct me if I'm wrong 👍) What do the parts that make up the domain or subdomain operate together to achieve?

I think it would be a shame to define a domain strictly as a business capability (as per #1 (comment))
because Strategic Domain Driven Design can show us how teams interact (much like @mploed s context map patterns).

I also think this addition is useful because it allows us to model our domains both now, and in the future. Or in the problem space and solution space.

TL;DR:
When we define bounded contexts we borrow from anthropology/ sociology and look for ubiquitous language
When we look for domains we should borrow from anthropology/ sociology and look for incentives

[benvand]

This has been really useful for getting to grips with defining domains within public sector organisations which are often:

• not driven by a classical profit motive
• often broad in scope (containing multiple, sometimes competing sub-domains)
• subject to frequent changes in required outcomes

As you can probably get from the above I wouldn't say an organisation:(core?)domain is a 1:1 mapping necessarily, however, and to illustrate my point about incentives, I think in profit driven organisations this definitely can be the case.

[NTCoding]

Hi @benvand,

A lot to think about, but all good, thanks.

I'd like to propose extending the Strategic Domain Driven Design definition of a domain/ sub-domain to explicitly recognise 'incentive'.
'Incentive' has a clear dictionary definition so is not creating ambiguity.

The metaphor I am using is landscape: (Sub)domains represent our view of the landscape we are operating in. The landscape is the whole map, and the (Sub)domains are our boundaries on that map, that help us to give names to areas.

At first, I struggled to think about how incentive would fit here (maybe you broke my model). But then I thought: a domain is our subjective view of a landscape. If a (Sub)domain is in our landscape, there needs to be a purpose. Could that purpose be our incentive for choosing the domain?

Example: Scooter Rental Company
Subdomain: Scooter Repair
Incentive: The Scooter Rental Company's incentive for Scooter Repair domain is to keep their fleet of scooters operational.

Does that work, or am I heading in the wrong direction?

I think it would be a shame to define a domain strictly as a business capability (as per #1 (comment))
because Strategic Domain Driven Design can show us how teams interact (much like @mploed s context map patterns).

I think I would position this as Domains are a better way of thinking about business capabilities.

Also, in EA the definition of a business capability does include the expertise and people needed to develop it. I agree that @mploed's context mapping is a key aspect of socio-technical architectures.

TL;DR:
When we define bounded contexts we borrow from anthropology/ sociology and look for ubiquitous language
When we look for domains we should borrow from anthropology/ sociology and look for incentives

Well summarised. I'm going to spin this up on a background thread (in my brain) and see what happens.

[benvand]

Thanks @NTCoding yeah totally on the right thread.

Happy to discuss more if you like

I think I would position this as Domains are a better way of thinking about business capabilities.

I agree. Also I missed your blog post before I posted this :)

Example: Scooter Rental Company
Subdomain: Scooter Repair
Incentive: The Scooter Rental Company's incentive for Scooter Repair domain is to keep their fleet of scooters operational.

With reference to your example the business has an incentive to sustain the domain because it makes sure they have working scooters. The business may also put pressure on the domain to keep x percentage of scooters operational. So the domains incentive is to keep scooters working. They're not working at odds to the highest level domain (ie financial profit) but they're also not incentivised to act totally in alignment.

[yellowbrickc]

Hi everyone,
I enabled discussiona for this repo, it could be helpful I think 🙂
Generally, I would be happy if we could come to a common understanding and merge this PR soon (it feels somehow as an open action point). We don't have to have the final solution, we could start with the first draft or the first term and iterate.

What do you think?

[NTCoding]

Hey @yellowbrickc. Great job enabling discussions, I didn't even know that feature existed.

I've closed this PR because I think we're all quite far away from reaching consensus. I will post something to my personal space and maybe in the future when we reach a consensus in the community about these terms we can try again in DDD Crew.

As a useful takeaway from this conversation, I would summarise: be very careful when using problem/solution space in DDD. When you say those words other people will be thinking of something different to you.

[yellowbrickc]

Hi @NTCoding
I must say, you are constantly challenging my views of Open Source repos and MRs 😆

I still think that it would be important to sit down (in a meeting, not in writing) and set up the basic ruleset, how we handle these repos and what do we expect from ourselves and from each other, what is our commitment as ddd-crew member. Maybe I'm not the only one in @ddd-crew/crew having this need - or maybe I am. It would help me anyway as both outcomes will tell me something.

Fact is: a lot of people spent time and energy to have these quite hard conversations (I mean both MRs) and the result for the community is an empty repository.

Don't get me wrong, I can totally understand that you publish your thoughts on your blog - I was asking myself the whole time, why not going that way but starting this Repo here 🤔 But you did start it and now the result is somehow unsatisfactory. Even if I don't think that we need to agree about every dot and hyphen, we could still sit down and formulate a fuzzy-enough-concrete-enough definition for each of those terms, as a start. The numerous participants in this conversation are proof that people would take responsibility and ownership and would invest energy to fulfil this task. But: until we don't know the rules of the game in this repo nobody would feel enabled to do the next step.

[NTCoding]

Hey @yellowbrickc

I think opening this repo was a journey of discovery. At the start it seemed like a good idea but along the way we realised that there are too many different interpretations among the community and there are no clear definitions.

While I agree that having an empty repository may seem unsatisfactory, I also feel that having something just to avoid an empty repository would be the sunk cost of fallacy. From my perspective, I have seen my clearly-defined defined definition, and I have seen your clearly-defined definition, but other people haven't had chance to fully explain their competing definitions, so I don't want to force my opinion when we don't have the common ground.

I feel that the conversations in these PRs are themselves useful which is why I decided to keep the repository and not delete it.

I don't think there is enough common ground to even have fuzzy basic definitions either unfortunately. There are big differences around problem/solution space. Unfortunately, other definitions are built on top of problem/solution space so we can't define others until problem/solution space is defined.

Overall, I'm happy with how things ended up. I would like to have reached shared agreement but I don't want to force my opinions. For now, making the lack of common ground visible has been a good step forward and maybe in future we will start to converge after people have had chance to reflect. I am hoping the VDDD meetup on this topic will help us to move forward.

What do you think?

[yellowbrickc]

Thanks for sharing your thoughts, I understand the outcome better now :)
I agree with all what you wrote but our missing capability to create those half-fuzzy definitions. I'm not disagreeing, I would say I'm rather more optimistic then you are.
I think a series of "Definition Workshops" would be a good way to go. Even If I don't like closed groups, I still would not organize it as normal public VDDD sessions but closed with those who participated in these conversations and are still willing to participate. This way we could have a good start to merge and reiterate later.

I forgot a very important part of my feedback: thank you for starting these conversations 👍