How do you apply DDD to different types of domains?

If you look at any business or enterprise in the context on an industry, you will always find functions that are core to that enterprises existence example for Retail banking these could be new customer onboarding, account management, credit management etc. For an airline, these could be reservations, tickets, managing operations, maintenance etc. such functions would be centralised around core domains that expose their business capabilities as a set of products. Product examples such as account, credit card, KYC.

I think it was useful. As essentially it states the importance of the core domain in DDD. It suggests investing time and resources, applying DDD techniques, aligning with business vision, and refining through feedback and experiments.

DDD helps modularise a system for easy working structure, maintaining and better yet adding features. The business logic defines application and thus working it out without the interference of the database to use or the router eases the load

Applying Domain-Driven Design (DDD) to different domains involves understanding the domain's core concepts and creating a common language. You then use design patterns to organize and represent the domain's elements, like groups of objects (Aggregates), individual objects (Entities), and characteristics (Value Objects). This helps capture the domain's rules and logic effectively. It's like building a tailored framework for each domain to make complex things simpler and well-structured.

Implementing core domains while using Ubiquitous Language while implementing Rich Domain Models without any infrastructure dependencies is the best thing I can think of.

I liked the simple approach in this snippet. As the snippet explains that the supporting domain in DDD is the part of the business that enables the core domain but is not directly tied to competitive advantage. It suggests using less sophisticated DDD techniques, decoupling it from the core domain, and optimizing for efficiency and reliability.

In Domain-Driven Design (DDD), supporting domains are crucial but not unique to the business. As a solution architect, you recognize that these domains assist the core domain by providing necessary functionality without being the primary focus. Supporting domains can include administrative tools, reporting systems, or other internal processes that facilitate the operation of the core domain. While they are essential for overall functionality, they do not differentiate the business in the market. Efficiently designing and integrating these domains ensures they complement the core domain, enhancing overall system performance and business operations.

I do not think this is a reasonable statement, as logging, metrics, authentication, etc is more like infrastructure and has nothing to do with domain at all.

I’d consider these examples as cross-cutting concerns and infrastructure topics. These are not related to domain-driven design and should be implemented aside from the domain layer. Infrastructure components (such as frameworks) tend to implement these. For example error logging can be implemented by having a framework component listen to a domain exception or domain event. Authentication is typically implemented in an I/O layer (before domain logic is executed). In some special and rare occasions, domain logic needs to be adjusted to be aware of a infrastructure interface to some extent (e.g to implement precise observability in performance-intense scenarios).

In my experience, generic domain should not consume any business events. Interaction with generic domain should support both synchronous (like REST) and asynchronous (Message command pattern) call. An example of generic domain like SMS/Email/App based two factor authentication. It can hold Unique ID, supported two factor, metadata like mobile, email etc. APIs like re/generate code, validate code, remember me like "Don't ask code for X days", expiry of code can be configured based on two factor type. Unique ID of generic domain can be a foreign key relationship to customer id, supplier id, vendor id etc in the respective core domain or supporting domain. Best part is generic domain gives a feel like it is a separate sellable product.

In Domain-Driven Design (DDD), generic domains are standard solutions used across various industries. As a solution architect, you leverage these domains to address common problems that are not unique to your business. Examples include authentication, logging, or payment processing systems. Generic domains often rely on off-the-shelf solutions or established patterns to minimize development effort and risk. By utilizing these ready-made components, you can focus resources on the core domain, ensuring the business’s unique value proposition is prioritized. Integrating generic domains effectively enhances efficiency, reduces costs, and accelerates overall development.

I’m not sure I’d call feature-driven development a trap, nor is technical debt a side effect of agility. Although a requirements modelling approach in its own right, features in feature-driven development are synonymous with User Stories, a standard delineation of a piece of work in agile approaches such as Scrum and Kanban. Technical debt can be the result of any short cut taken tactically, at least with an Agile approach the opportunity to pay back that debt can be identified and prioritised as soon as it is identified.

The fusion of Domain-Driven Design (DDD) with agile methods is a recipe for success. Agile practices like Scrum and Kanban inject speed into DDD, enabling swift value delivery and iterative improvements. This synergy allows teams to refine the core domain while efficiently adapting supporting and generic domains based on customer feedback. However, balance agility with strategic foresight to avoid feature-driven pitfalls or technical debt. Agile methods align with DDD's goals, nurturing the core domain, prioritizing other domains, and ensuring code quality's continuous enhancement. This partnership empowers innovation within an agile framework, maintaining alignment with business objectives.

I’m not sure DDD has anything to do with patterns. Domain Driven Development helps to reflect business into the code. Like building objects and their behavior as close as the are in the domain they operate. I’d say this statement is somewhat misleading

In my experience the DDD is quite resourceful in the aspects of separation of concerns. DDD is easy to work with maintain and evolve. But everything is subject to change-- the best way of applying something is know the rules and then break them to fit you goal.

DDD is actually a collection of industry patterns and practices. While give me opportunity to learn many new patterns and simplify complex domain problems in simply rich domain models.

In Domain-Driven Design (DDD), patterns are essential for structuring complex systems. As a solution architect, you apply these patterns to ensure alignment with business goals and to manage complexity. Key DDD patterns include: 1. Entities: Objects with a distinct identity that persists over time. 2. Value Objects: Immutable objects that describe aspects of the domain without identity. 3. Aggregates: Clusters of entities and value objects treated as a single unit to ensure consistency. 4. Repositories: Abstractions for accessing aggregates from a data store. 5. Services: Operations that don’t naturally fit within an entity or value object.

I liked it as well, In my professional opinion, the snippet provides a balanced view of the advantages and disadvantages of domain-driven design (DDD). Additional Advantages are: Easier integration and evolution of the system: DDD promotes modular design and bounded contexts, enabling easier integration of different components. It also allows for the gradual evolution of the system as new requirements emerge, making it more adaptable to changing business needs. In conclusion, I think the snippet provided good value in a short text.

Another crucial factor which should be considered while doing the trade off, is the cost analysis of developing and maintaining required infrastructure. Event streaming platform, CI/CD solution, docker orchestration system are some of the examples. the company would probably need to also hire a dev-ops specialist to keep these infrastructures up and running. these costs should be considered once one is opting to choose this pattern.

I use it all the time in my projects - Golang projects. The aspect of building an interface that can be swap easily is more resourceful in my coding. for example you can use two databases that implement an interface expected by the service or business logic.

DDD attack at the heart of complexity. Levering industry patterns and practices, within the bounded context and using domain specific language (Ubiquitous language)

As a solution architect, embracing Domain-Driven Design (DDD) offers several benefits: 1. Alignment with Business Goals: Ensures the software design closely matches the core business processes and requirements. 2. Improved Communication: Establishes a common language between developers and domain experts, reducing misunderstandings. 3. Flexibility and Scalability: Modular design with clear boundaries makes it easier to adapt and scale. 4. Enhanced Maintainability: Well-defined domains and patterns lead to more manageable and understandable code. 5. Focus on Core Domain: Prioritizes the most valuable and differentiating aspects of the business, optimizing resource allocation.

Applying Domain driven design (DDD) requires significant discipline and organisation maturity such as aligning the enterprise to a common domain model, identifying core processes and decompose them, getting the right stakeholders from business and IT perform event storming on those processes or sub process and more. All to identify the right set of capabilities that are owned and managed within a domain and exposed within the enterprises through well defined technical capabilities.

While Testing in DDD, I consider Use-Case testing instead of domain model testing due to ever-changing requirements. But sometimes I have to test in depth domain models for complex business requirements.