Intro

So why knowing the concept of DDD is important? because:

• Then we understand how companies operate within their business.
• We can design good systems that are aligned with the business goals.
• Understanding the business is a fundamental requirement to build successful software solutions.
• Helps break down a complex problem space into smaller, manageable “domains”.
• Foster effective communication through shared, precise vocab (learn more about ubiquitous language).
• Maps business logics/rules/assumptions to the domains:
  • Correct reflection of business rules in code.
  • E.g. for a payment refund it should have been paid in full.
• DDD is about having a mental model shared by business people and devs.
• Clarifies on what each team is working, less miscommunication.
• The names of classes, variables and other implementation components should be consistent with a business nomenclature.

[!CAUTION]

# To simplify things let’s just think that we only have an API. So for the time being let’s say application = our backend.

Domain

• A specific area of a business.
• A certain thematic area in business.
• A specific area of knowledge, business logic, or functionality.
• A problem space concept that reflects a segment of the business.

[!NOTE]

By “specific area”, or “certain thematic area” we meant to say coherent and atomic.

• Subject matter or problem space that your application is designed to handle.
• All of them together form the business domain.
  • We model domains based on business’s needs.
  • Building blocks for your application’s functionality.
    • In other word, an implementation is created with consistency which reflects business rules by using building blocks.
• AKA a “group” or a “module”.

Palpable example in TS

A simple invoice billing domain files & folders.

The cost of DDD

• It asks for upfront investment:
  • Meetings with experts in that business.
  • A thorough understanding of the problems & needs of business.
• Not good when you have a small project such as multiple CRUD, which are usually not complicated.
• Good when your project involves the implementation of a large system with extensive business assumptions.

Different types of domains

• DDD is very elastic.
• DDD allows you to use it in specified parts of your solution.
• DDD + simple CRUD + external modules is OK.
• From a strategic perspective we usually group them by their complexity and importance for a company.

Categories
Core	Generic	Supporting
AKA core domains. What differentiates a company from another. The innovation that a company introduces to gain an advantage over its competitors (company's competitive advantage). If it is simple to implement is also simple to copy. Not necessarily technical. E.g. an ECommerce app for a carpenter. Change often (where you need to not stagnate). Core features of the API. Will be the core purpose of your application. The problem your software solution wants to solve.	Business activities that all companies do in the same way. Ready-to-use implementations are widely available. No real need for innovation or proprietary solutions here, e.g. auth. Contains logic which from a strategic perspective is not important as other core domain.	Necessary functions that enable the core domain to operate effectively. No real competitive advantage or business differentiation. The main criterion for distinguishing them: they're simple to implement. Usually CRUD-based systems.

Complexity of different types of domains

Identifying boundaries of domains

Separate core domains from the rest, ensuring proper design decisions. To do so we need meetings with domain experts and together try to understand obtained knowledge about the system.

• Core domains are defined by the:
  • Company’s business strategy.
  • Company’s business domain.
• Core domain use cases usually involve the same entities, and perform operations over closely related data:
  • Identify key entities; look at the nouns in the problem description or business process.
  • Map relationships; how do these entities interact?
  • Focus on user needs; think about what the users of the app need to interact with.
  • Leverage business logic; look at the operations and rules specific to the domain.
• In those meetings you can use:
  • Simple ubiquitous language with UML.
  • Custom notation.

Some examples

Vet helping system

Client says something like this:

I have a lot of patients nowadays and still, I'm using a notebook to schedule appointments and classic paper patients' documentations. It's hard for me to work with patients and at the same time scheduling visits or exporting patients' diagnoses for their owners. I can't afford a secretary in the long run so I've decided to implement a schedule and diagnosis system which won't need my attention to book patients or share the diagnosis with owners.

The custom notation of the entire flow of our vet helping system with authenticated users.

• The most important thing to you is to automate the registration process or provide a mechanism for storing a patient's diagnosis and data.
  • We don't have to use DDD for everything; authentication module is a normal module.
  • Core domain
    • Scheduling an appointment, canceling and list our appointments.
    • Attach consultation/diagnosis results during an appointment to registered pets and allow to read diagnosis for pets' owners.
• Less emphasis on the invoice system, which can be e.g. bought from an external company.
  Or you can implement it on your own, but as simple as it's possible. The invoice module is a generic domain.
• Implement a module responsible for calculating health level of a pet. A number between 0 to 10.Calculated according to the pet's blood tests results, diagnosis, and subjective vet mark.
  A cool feature to show that information or use it by the vet to make some decisions but it's not important business logic. This is a supportive domain.

Project structure for this example.