2

Let's say we are in a company that sells coffe mugs, providing a Domain-Driven Design approach for their architecture needs.

According to common DDD practices (i.e. in literature by Vaughn Vernon and Eric Evans, nicely summarized in this Medium article), a good starting point is to identify Core Domains, Generic Domains, Supportive Domains and Bounded Contexts. Then, the domains can fit into the Bounded Contexts. One domain can appear in more than one context, with different meaning (because of different context).

From my understanding, Bounded Contexts can be mapped to key business areas (not necessarily matching real depts. in the organization, but that's a different topic)

So let's say we have identified these Business Areas

  • Providers
  • Shipping
  • Payment
  • Delivery
  • Text Recognition

Let's focus on this last one. One of the key parts in the store is Text Recognition. The customer uploads a pic for it to be printed on the mug, and the backend performs Text recognition, to offer additional features based on the text it's found, like saving the design, tagging for sharing the designs in SNs with a hashtag, analytics... so on. Let's say that this Text Recognition is achieved through an external solution, like Google's Cloudvision.

The question I raised here is that, for me, Text Recognition is more a technical solution, than a Bounded Context itself. The other thinking stream we have, is that it should be reflected as a Bounded Context.

What do you think?

It's true that it's an "external" solution, so in a way it should be reflected in one of the usual DDD diagrams. But I think it fits better as a Generic Domain not a Bounded Context, and would be shown in the Contexts Mapping Diagram (which features domains).

Another topic that could help is Strategic vs Tactical DDD. I don't have a proper understanding of Tactical DDD yet. To me Providers, Shipping, Payment, Delivery contexts have sense in a Strategic DDD. But Text Recognition should not be mixed there, it has a more "Tactical" meaning to me.

EDIT: To clarify from the @Ewan 's question Does the business talk about Text Recognition as part of the business process? Not definitely. The business doesn't speak of "Text Recognition". It is not a software company. The term is only handled at the technical levels in it.

Could you add any other points I haven't thought of? Do you any other view on it?

I greatly appreciate.

Improve this question
6
  • I think you're missing a context. What bounded context does The customer uploads a pic for it to be printed on the mug belong to? The Text Recognition feature should probably be part of that context.
    – Rik D
    Commented Oct 6, 2020 at 9:52
  • Yes, it came to my mind that we should find a business term into which Text Recognition participates, which matches your question. In this example is easier, it could be Customization and also appear in other contexts to reflect the analytics and SNs usage.
    – amilletp
    Commented Oct 7, 2020 at 10:58
  • But in our real case is more difficult. I think that we have a clear defined context where Text Recognition participates. But to me, the important thing is that Text Recognition is not a candidate to be a Bounded Context in itself, that's the matter we are debating at work. It has been suggested that because is an external system, it should be made into a Bounded Context. I'd rather see it depicted as a Generic Domain, which participates in a Bounded Context for a real business are we have.
    – amilletp
    Commented Oct 7, 2020 at 10:59
  • *business area we have.
    – amilletp
    Commented Oct 7, 2020 at 11:06
  • But if we proceed this way (domain inside the BC) we have the problem on how to show it is an external system. In a Bounded Contexts diagram this level of detail isn't relevant. What is the best way according to DDD techniques to reflect it. Maybe context mapping maybe a Tactical DDD practice?
    – amilletp
    Commented Oct 7, 2020 at 11:36

2 Answers 2

Reset to default
2

I guess the underlying question is "what is a Bounded Context for you?".

From a modeling point of view, the text recognition library or component is a different model hence should be a separate bounded context. It's incredibly easy if you just draw it on paper: you don't want the internals of text recognition to leak into other models, and vice-versa.

What usually makes things complicated is "So, what should I do at the code level?" which in this case could build down to: let's make sure you don't want strong coupling to an external provider, and that you separate the client interface what your model needs from the externally provided interface what the tool offers.

PLUS: Bounded Contexts exist in the solution space, Domains exist in the problem space. It's two different ways of reasoning here.

Improve this answer
1
  • Thank you for your clarification on avoiding the leak to other models, as a key role of the bounded context. By yours and others answers I think that we are switching terms. I guess our understanding BCs is in fact, more in line with the de-composition of problem space into Domains. This seems to fit with literature, where Domains are related to business areas. I understand that Text Recognition can be expressed as a Generic sub-Domain, and that a Bounded Context of it, is a detail of the solution space to avoid leaking its model.
    – amilletp
    Commented Oct 11, 2020 at 12:09
2

To quote the article you reference:

A bounded context defines the limits of applicability for a ubiquitous language

Looking at your examples you probably have only a single Bounded Context, where Order, Payment, Delivery etc each has a single meaning and object.

You could pick any one of your Business Areas and Call it a bounded context, but unless you have a reuse of a term, say Payment in the providers business area has a completely different meaning to Payment in the Payment business area, its not going to make any difference.

A text recognition library is unlikely to use any of your business terms. Perhaps you have a process withing ordering where the automated recognition is tried and if not at a high surety level a human process is used and there are business language terms in that which overlap?

Where you can choose the names of things its best to stay in a single bounded context and simply change the names.

Improve this answer
17
  • An Order in a Payment context has properties and methods related to pricing, while an Order in a Shipping context has properties and methods related to weight and dimensions and addresses. So while the limits of language is one reason to create separate bounded contexts, it is not the only reason.
    – Rik D
    Commented Oct 6, 2020 at 12:19
  • having two objects for the same thing is a mistake in my opinion. take those methods off and put them in processing classes
    – Ewan
    Commented Oct 6, 2020 at 12:21
  • This question is about Domain Driven Design and in that regard creating multiple objects representing the same thing in different contexts is considered best practice. Services or processing classes that work on DTO objects is on the complete other end of the spectrum and is what DDD tries to prevent.
    – Rik D
    Commented Oct 6, 2020 at 12:26
  • 1
    I'm going to mostly agree with Ewan here. It's all about modeling; you don't necessarily go in with the mindset that you want to find multiple contexts. It's just that, as you conceptualize & model the software to support the needs and business processes of an organization, you notice that there are sub-aspects of it that (1) use same terms to mean different things, and (2) pull the project in different directions, making it all tangled and complicated, so you decide to represent the different aspects with different models, and make the boundary (and interop points) explicit.
    – Filip Milovanović
    Commented Oct 7, 2020 at 16:31
  • 1
    Really, the practice can be seen as SRP applied at a larger scale, within the modeling process. It's just about making a conscious decision to have two (or more) simple(r) models instead of one model that's large, unwieldy, and a big ball of mud. The industry has been very confused about this. What's worse, many people seem to equate BCs with microservices, but that's 99.9% of the time too granular, so it leaves you with a big "unbounded", implicit context at the system level, thus defeating the purpose of BCs.
    – Filip Milovanović
    Commented Oct 7, 2020 at 16:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.