How to sound like a pro on Domain-Driven Design

How to sound like a pro on Domain-Driven Design

Why it is smart to start investing in the stock market?

Lorem ipsum dolor sit amet, consectetur adipiscing elit lobortis arcu enim urna adipiscing praesent velit viverra sit semper lorem eu cursus vel hendrerit elementum morbi curabitur etiam nibh justo, lorem aliquet donec sed sit mi dignissim at ante massa mattis.

  1. Neque sodales ut etiam sit amet nisl purus non tellus orci ac auctor
  2. Adipiscing elit ut aliquam purus sit amet viverra suspendisse potenti
  3. Mauris commodo quis imperdiet massa tincidunt nunc pulvinar
  4. Adipiscing elit ut aliquam purus sit amet viverra suspendisse potenti

Should I be a trader to invest in the stock market?

Vitae congue eu consequat ac felis placerat vestibulum lectus mauris ultrices cursus sit amet dictum sit amet justo donec enim diam porttitor lacus luctus accumsan tortor posuere praesent tristique magna sit amet purus gravida quis blandit turpis.

Odio facilisis mauris sit amet massa vitae tortor.

What app should I use to invest in the stock market?

At risus viverra adipiscing at in tellus integer feugiat nisl pretium fusce id velit ut tortor sagittis orci a scelerisque purus semper eget at lectus urna duis convallis. porta nibh venenatis cras sed felis eget neque laoreet suspendisse interdum consectetur libero id faucibus nisl donec pretium vulputate sapien nec sagittis aliquam nunc lobortis mattis aliquam faucibus purus in.

  • Neque sodales ut etiam sit amet nisl purus non tellus orci ac auctor
  • Adipiscing elit ut aliquam purus sit amet viverra suspendisse potenti
  • Mauris commodo quis imperdiet massa tincidunt nunc pulvinar
  • Adipiscing elit ut aliquam purus sit amet viverra suspendisse potenti
Is it risky to invest in the stock market? If so, how much?

Nisi quis eleifend quam adipiscing vitae aliquet bibendum enim facilisis gravida neque. Velit euismod in pellentesque massa placerat volutpat lacus laoreet non curabitur gravida odio aenean sed adipiscing diam donec adipiscing tristique risus. amet est placerat in egestas erat imperdiet sed euismod nisi.

“Nisi quis eleifend quam adipiscing vitae aliquet bibendum enim facilisis gravida neque velit euismod in pellentesque massa placerat.”
Tell us if you are already investing in the stock market

Eget lorem dolor sed viverra ipsum nunc aliquet bibendum felis donec et odio pellentesque diam volutpat commodo sed egestas aliquam sem fringilla ut morbi tincidunt augue interdum velit euismod eu tincidunt tortor aliquam nulla facilisi aenean sed adipiscing diam donec adipiscing ut lectus arcu bibendum at varius vel pharetra nibh venenatis cras sed felis eget.

Here at Orbit we like to use Domain-Driven Design (DDD) when designing software in customer projects. A process we have described prior at this blog, while we have also written about how to create modular monoliths with the use of DDD. So why another blog post on DDD? The main motivation stems from occasions in Orbit Tech where we have had slightly different understandings of concepts in DDD, which have resulted in some mis-communication and thus less effective group work. To overcome this, my ambition with this post is to be very firm on definitions of DDD. Thus, allowing us (and you) to communicate effectively. And hey - who doesn’t want to sound like a pro on DDD? 😊

Before we take off, I just want to briefly introduce the main source for this post, which is the original book on DDD written by the person who first coined it in 2003 aka. Domain-Driven Design by Eric Evans. Whenever it is cited it is referenced as [DDD, page number].


  • The heart of software is its ability to solve problems for its users within a domain. A domain is an activity, e.g. booking people on air flights.
  • Representing the domain in software is often the biggest source of complexity in projects (not technology)
  • DDD is a toolbox for tackling complexity by designing a model, which can be implemented in code, that accurately represents the domain, called the “domain model”.
  • A domain model often includes ubiquitous language, bounded context and aggregates.


To start off common ground, let’s frame the why. To do so, we should start with Eric Evans' fundamental perspective on software. In his view “the heart of software is its ability to solve problems for its users” [DDD, 4]. While “... the most significant complexity of many applications is not technical. It is in the domain itself, the activity or business of the user.” [DDD, xxi].

Let’s set this straight with an example. Let’s say we are to program an air flight booking system, e.g. something like According to Evan, the main complexity in doing so may not be technical, e.g. how to use NodeJS or Typescript. Instead, it may be to accurately model the activity of the user. E.g. how to ensure that seats are booked just once? Or how to price flights according to their availability?

However, we still haven't explained the importance of DDD in this view on software. The author presents DDD as a “framework for making design decisions and a technical vocabulary for discussion domain design”. [DDD, xix] Although vaguely, this quote points to the role of DDD. The way DDD proposes to reduce complexity in software projects is to create models, which can be implemented in code, that accurately represent the domain, i.e. the activity of the user. Such models are called “domain models”. DDD provides a “toolbox” for discussing and designing these - hence its critical importance. Now having understood the purpose of DDD, let’s look into its toolbox.


The book by Eric Evans provides an (overwhelmingly) wide array of ideas for constructing domain models. We haven’t got time to go through them all in this post. Instead, we will focus on a few, often used ideas. These will be explained along with an excerpt from a customer project.

The customer project is to model how damage claims of some selected vehicles are being processed. Figure 2 illustrates the strategic design of the project. The term “strategic design” is used in DDD to describe “modelling and design decisions that apply to large parts of the system.”. [DDD, 514] This may just be called “software design” in many projects.

Without going into more detail about the functionality of each of the entities constituting the strategic design, let’s look at the concepts originating from DDD:

  • Ubiquities language: A common language used by engineers and domain experts to allow for effective communication across diciplines. E.g. names like DamageClaim and Company in figure 2 are part of the ubiquities of language for the project.
  • Core domain: “The specialised core, that part of the model that really differentiates the application and makes it a business asset”. [DDD, 401] Or in short, the reason for the project. If we had no core domain, we should have bought standard software.
  • Aggregate: “A cluster of associated objects that are treated as a unit for the purpose of data changes. External references are restricted to one member of the aggregate… the root.” [DDD, 511]. E.g. DamageClaim is an aggregate that encapsulates two entities, DamagedParty and DamagingParty. Whenever any of the aggregate’s members are requested, the request must go through the aggregate, so that the business logic in the aggregate is maintained at all times. E.g. some entity must be notified when a DamagedParty is created.
  • Entity: “An object fundamentally defined… by a thread of continuity and identity.” [DDD, 512]. E.g. A DamagedParty is a unique identity that we want to keep track of at all times. Hence, we must rely on a single instance in memory that we reference, so that changes within a single process are not overwritten.
  • Value object: “An object that… carries no concept of identity” [DDD, 514] “These are the objects that describe things”. [DDD, 98] Contrary to an entity, a value object is an immutable entity that we can create (and destroy) at will. An example of such is a Date object. This simplifies the code, as we do not need to keep track of a single instance.
  • Bounded context (Context): A context encapsulates aggregates and entities that “belong together”, while separating distinctive ones. Two bounded contexts can have two different ubiquitous languages and thus may have different meanings for the same words. Separation of distinctive entities prevents software from becoming buggy. [DDD, 336]
  • Anticorruption layer: “Create an isolating layer to provide clients with functionality in terms of their own domain model.” [DDD, 365]. This is an API to some functionality. One way of implementing it is a “combination of Adapters, Facade and Translators”. [DDD, 366].
  • Published language: “translation between models of two bounded contexts requires a common language”. (DDD, 375). This is some general published language on how to access some functionality, e.g. that of the DamageClaim-Context. The language may be published by using Swagger.

Now, I could have talked at length about each of the concepts. Nevertheless, I still believe that the short walk-through pinpoints some of the key takeaways to understand DDD’s toolbox. We may decide in a future post to go into detail with these and more DDD tools. At last, thanks for reading along thus far - I hope you’ve deepened your understanding of DDD. Also, please leave a comment if you have any remarks.

About the author
Subscribe To Our Newsletter - Bnkly X Webflow Template

Subscribe to our newsletter

Thanks for joining our newsletter
Oops! Something went wrong while submitting the form.