#What is essence of domain driven design and it's relationship to microservices architecture

1 messages · Page 1 of 1 (latest)

heady socket
#

Several questions:

  • What is essential stuff that somebody should know about DDD, like main idea(s)?
  • What is good to know about DDD when it comes to microservices?

I started to read book building microservices and DDD was mentioned, specifically three terms: ubiquitous language, aggregate and bounded context. What I remember from reading is that with regards to ubiquitous language, language that is used with non-developers should be same in the code and between the programmers.

For aggregate this is got from reading and what I noted

Aggregate could be considered as a representation of the real domain concept.

We want to treat aggregates as self-contained units; we want to ensure that the code that handles the state transitions of an aggregate are grouped together, along with the state itself. So one aggregate should be managed by one microservice, although a single microservice might own management of multiple aggregates.

For boundary context

A bounded context typically represents a larger organizational boundary.

It is better that each microservice handles a particular entity separately, so as not to share identity.

Sometimes it is good to chunk up our architecture, meaning break bounded context into several microservices, to simplify testing.

rain patioBOT
#

<@&987246841693360200> please have a look, thanks.

rain patioBOT
#

While you are waiting for getting help, here are some tips to improve your experience:

Code is much easier to read if posted with syntax highlighting and proper formatting.

If nobody is calling back, that usually means that your question was not well asked and hence nobody feels confident enough answering. Try to use your time to elaborate, provide details, context, more code, examples and maybe some screenshots. With enough info, someone knows the answer for sure.

Don't forget to close your thread using the command </help-thread close:1027500463647621170> when your question has been answered, thanks.

#

Here is an AI assisted attempt to answer your question 🤖. Maybe it helps! In any case, a human is on the way 👍. To continue talking to the AI, you can use </chatgpt:1108714622413963314>.

#

is the relationship between DDD and microservices architecture?

  • How does DDD help in designing microservices?

Domain-Driven Design (DDD) is an approach to software development that focuses on understanding and modeling the core business domain. The main idea behind DDD is to align the software design with the business domain, making it easier to understand, maintain, and evolve over time.

Some essential concepts of DDD include:

  1. Ubiquitous Language: DDD emphasizes the use of a common language between developers and domain experts. This language should be used consistently throughout the software development process, from requirements gathering to code implementation.

  2. Bounded Contexts: A bounded context is a specific area within a system where a particular model or set of models applies. It defines clear boundaries around different parts of the system, allowing for better organization and understanding of complex domains.

  3. Aggregates: Aggregates are clusters of related objects that are treated as a single unit. They encapsulate business rules and ensure consistency within their boundaries.

Now, regarding the relationship between DDD and microservices architecture:

#

Microservices architecture is an architectural style that structures an application as a collection of small, loosely coupled services that can be developed, deployed, and scaled independently. DDD can be seen as a complementary approach to designing microservices.

DDD helps in designing microservices by providing guidance on how to identify service boundaries based on bounded contexts and aggregates. By understanding the core business domain through DDD techniques like modeling, ubiquitous language, and bounded contexts, developers can define appropriate service boundaries that align with business requirements.

Additionally, DDD helps in maintaining consistency within each microservice by encapsulating business rules within aggregates. Each microservice can have its own internal model based on its specific bounded context while still adhering to overall business rules defined by the domain model.

In summary, DDD provides principles and techniques for understanding complex domains and aligning software design with business requirements. When applied to microservices architecture, DDD helps in defining service boundaries and maintaining consistency within each microservice.

manic monolith
#

if you dnt want to post the other one, consider closing it

#

with command /help-thread close

heady socket
manic monolith
#

alright, so you're interested in learning ddd right

heady socket
manic monolith
#

Domain-Driven Design (DDD) is an approach to software development that focuses on understanding and modeling the core business domain. The main idea behind DDD is to align the software design with the business domain, making it easier to understand, maintain, and evolve over time.

#

notice: "is an approach"

#

A rule of thumb: any software has layers like view, persistence, security, connections

#

each of those require businss logic

#

this is where DDD comes into action

#

the businessLogic is split into 3 coarse grained components called Domains

#

Consider Kinder company, it has a very good chocolate ! that's one its domains

#

a company may have more than one domain at a time

#

each domain is composed of SubDomains

#

a subdomain can be a software component or nonsoftware (like the domain)

#

SubDomains are 3 types:

  • Core
  • Generic
  • Supportive
#

core subdomains is the most important components

#

for Kinder company, the chocolate secret receipt is a subdomain.

#

for Google company, the search engine is the core subdomain

#

for Meta the core subdomain is the social media facebook, and so on

#

core subdomains are competitive, they are hard to be reproduced by other companies

rain patioBOT
#

In Domain-Driven Design (DDD), subdomains are used to divide a large and complex business domain into smaller, more manageable parts. These subdomains help in organizing and understanding the various aspects of the domain. Three common types of subdomains in DDD are core, generic, and support subdomains.

  1. Core Subdomain:
    The core subdomain represents the heart of the business domain. It contains the most critical and unique concepts, rules, and processes that differentiate the business from others. The core subdomain encapsulates the main value proposition and competitive advantage of an organization. It is typically where most of the business logic resides and where significant effort is focused during development.

  2. Generic Subdomain:

rain patioBOT
# rain patio In Domain-Driven Design (DDD), subdomains are used to divide a large and complex...

The generic subdomain represents common functionalities or capabilities that are not specific to a particular business domain but can be reused across multiple domains. These functionalities are usually non-differentiating aspects of a system that can be standardized or outsourced. Generic subdomains often include features like user authentication, payment processing, logging, email notifications, etc. They provide reusable components or services that can be shared among different parts of an application or even across multiple applications.

  1. Support Subdomain:
    The support subdomain represents auxiliary functionalities required to enable or facilitate core operations but do not directly contribute to the primary value proposition of the business domain. Support subdomains often include features like reporting, analytics, data import/export, administration tools, etc. These functionalities assist in managing and maintaining the system but are not essential for its core operation.

It's important to note that these categorizations may vary depending on the specific context and nature of each domain. The goal is to identify distinct areas within a complex business domain so that they can be effectively modeled, developed, and maintained separately while ensuring proper collaboration between them when necessary.

manic monolith
#

I tried to get some help from chatgpt as i dn't have much time. try to learn as possible as u can, and tell us if you have questions.

heady socket
manic monolith
#

you start developing them as services

#

you may have one or 2 i dunno

#

it depends on your business objectives

#

as for non competitive components/apps/services

#

you may try to use third party platforms to not waste time in dev

#

like Keycloack for authentication/authorization

#

based on DDD you're going to know what you'll need to develop exactly

#

there is no direct relationship between microservices and ddd

#

but DDD can help you build effectives microservice-like systems

#

you need to be aware of the nouns that i gave to you first, domains, subdomains

#

once you've done designing your system (could be in diagram)

#

you can start defining a ubiquitos language

#

a language that must be used commonly between business specialists and software specialists

#

it could also be applied in code (classes, interfaces, fields, methods)

manic monolith
heady socket
heady socket
ripe linden
#

It is alright if the discussion continues here, interested folks can still participate and contribute if they wish to. Plus the context is lost when you switch to separate channel in the middle of conversation. on a sidenote, Threads are always up for a good discussion.

manic monolith
#

After designing your system and understand the why and what of it (business objectives)

#

You can start your 1st core service

#

Java develoeprs usually use spring boot and spring cloud

#

Example: service-core A

#

You put the core features of your system there, then you add support subdomain like a library for persistence or objects builders

heady socket
# manic monolith Ive told you how.

Yeah, I wondered whether there is more that could be said other than

when you identify your core subdomains
you start developing them as services

and a ubiquitos language

manic monolith
#

A ubiquitos language means you define some terms between you, your team and domain experts (end users and domain specialists)

#

For example your system is about doing complex searches like Google Engine

#

You define some entities like : Website, Link, Keyword, Book, Video

#

These can be read easily by anyone, you can then define them, their behaviors, their relationships in code

#

Like this SearchWebsiteEngine

#

You make your code based on the domain requirements

#

Also, when writing technical spec such as Readme

#

You explain how components are defined in diagrams (like conceptual model)

#

And you use same terms

#

It's like a boundary in the domain where you are

#

You dnt get out of it, regarding the ddd principles

#

Btw for tests there is a tool to enhance communication between developers and testers, following a ubiquitos lang

#

Like Gherkin

rain patioBOT
#

Closed the thread due to inactivity.

If your question was not resolved yet, feel free to just post a message to reopen it, or create a new thread. But try to improve the quality of your question to make it easier to help you 👍