In literature (blogs, articles, books on Enterprise Architecture...), it seems there is a real (and exclusive) appliance of SOA in EA. If we consider DDD and SOA share common architecture principles but differ on many others, what is the place for DDD in the EA discipline ?
DDD and SOA play well together. Usually service boundaries match with your bounded contexts. You design cross-context communication using SOA and it all works. EA does not go deep into how you develop your "services" inside but DDD helps you there.
For me the greatest advantage of DDD is that it makes you do your work when analysing the business domain.
Good understanding of the domain is never a bad thing, and of course this statement holds true for SOA as well. Even more, if you manage to build a common data model for most entities, this improve interoperability because you will be able to build much more standardised services, so you will avoid the need for data mapping and transformation. When you do service composition and/or orchestration common types tend to become a must. So if you put in more work upfront, you're going to have easier times later when your services and inventories get to governance.
As Alexey already stated, DDD and SOA do not interfere and work well together.
In his book, SOA Design Patterns, Thomas Erl describes how softwares end up being composed of and residing in architectural elements which could be technological, platform or resource related. He then explains the importance of technology architecture in service-orientation and it's four common types of which are:
Service Architecture
Service Composition Architecture
Service Inventory Architecture
Service-Oriented Enterprise Architecture
For as far as technology architecture is concerned, there is no mentioning of how the services should be implemented (DDD or otherwise). It just emphasises on their existence, their composability and their boundaries.
Domain Driven Design, covers the "how" of software component design. And that's exactly what happens in the book. When narration swings to design patterns, topics such as Domain Inventory and Entity Abstraction come into the picture.
So for as long as a design approach complies to four characteristics of SOA (business driven, vendor neutral, enterprise centric, composition centric) and it's design principles (standardized service contract, service loose coupling, service abstraction, service reusability, service autonomy, service statelessness, service discoverability, and service composability), which in my opinion DDD does, it could be safely used for design and implementation of a software and it's services.
DDD, as one EA guru (I believe it was Gary Booch) once stated, was a result of misunderstanding of EA by the DDD author (in his DDD book, he mixed the concepts from conceptual, logical, physical, implementation, and operation perceptions - a very, very dangerous thing!).
Basically, when you talk about EA, you must always discern between different viewpoints (to borrow the term from Zachman EA Framework) and model the architecture within the boundaries of the specific viewpoint you are concerned with in a particular phase of the EA development process. E.g.
Identify (types)------SCOPE--------Planner perception----Row I ZF
Define (business)-----CONCEPTUAL------Owner perception-----------Row II ZF
Represent (system)----LOGICAL---------Architect perception-------Row III ZF
Specify (technology)--PHYSICAL--------Engineer perception--------Row IV ZF
Configure (tools)-----IMPLEMENTATION--Sub-contractor perception--Row V ZF
Manifest (operations)-INSTANTIATION---Operator perception--------Row VI ZF
In other words, DDD author got it all wrong, he mixed up apples and oranges. Basically, back in early 2000s when he wrote the DDD book, he was not familiar with EA research (the 1st version of Zachman Framework was published in late 80s, but it did not proliferate with the business community for quite some time).
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I am a web developer, I want to become software architect, and I learn everyday about it, but when I am learning software architecture I see TOGAF framework for enterprise architecture, I want to get solid understand in an enterprise architecture.
Overview
Enterprise architecture focuses on the future state solution for : Current business problem , business strategy , business process improvement (BPI), business process re-engineering and business adventures. If you ask one enterprise architect what they are working on, most likely you are going to find out that they are working on one of these areas, unless they have a more specialized domain, which we cover later in this article.
“The What”
Enterprise Architecture does not prescribe the “how” only the what,
Deliverables
Depending on your company solution lifecycle standards and templates, your deliverable may be called “solution architecture”, “Enterprise Architecture blueprint” or some other name.
Architecture layers
It is a good practice to include in your deliverable minimum six architecture layers:
Security: End to end view of your solution from security perspective, this captures authentication and access management, data in transit and at rest protection.
Application: A view of your solution from the application perspective, includes domain specific programming language, and application design patterns and decisions for your font end, back-end and middle tier.
Infrastructure: This layer shows a view of your running platform, it may include cloud, containerization and virtualization.
Information: This captures your entire information lifecycle management from data modeling to acquisition, classification, and retirement.
Network: This architecture layer depicts the network end points and their paths.
Integration: This layer shows your data transportation and systems conversations, for example it shows your separations of data transportation from orchestration.
While these layers are not the only layers hat you can add to your architecture, you can add more as needed for example “business continuity” and “devops”, but all depends on the type of your organization and objectives.
The Enterprise Architect role
Being an Enterprise Architect (EA) entails command in multiple domains , however most of us in this industry started our careers in one domain such as development, networking, DBA, etc, an architect usually have expertise in at least one of the following and experience in the rest.
Expertise in one programming language (expert level means very familiar with the language and design patterns specific to the language).
Expertise in one database vendor ( Oracle, MSSql, DB2) expert level means - - Expertise in SQL , SQL:2016 being the latest standard in addition to server side language (PLSQL, TSQL)
Experience in networking basic concepts of networking and knowledge of new trends such as software defined networks (SDN).
Experience in integration patterns
Experience in infrastructure such as cloud , virtualization and containerization
Experience in information security: Identity and access management , Data in transit and data at rest protection.
In addition basic knowledge in : Data modeling, data warehousing, big data, Web UI frameworks, major cloud providers, compliance (ie: PCI, HIPPA), IPV4, IPV6, SOA.
And also helps if you have your own vision of the future landscape (ie: server-less , self-rendering services )
Architecture frameworks
There are multiple frameworks that depending on the situation may fit in your deliverables, these frameworks try to address the common architecture patterns in a prescriptive way.
TOGAF
Zachman
DoDAF
To answer your question " what s the difference between system architecture, application, software architecture":
Application architecture is one of the layers in your architecture.
System architecture, software architecture, solution architecture can be used interchangeably. Just don't lose your the big picture .
Some of the inputs for the architecture are
business strategy.
use cases
business cases.
Business continuity strategy
Compliance
Some of the outputs are
High level designs
A vertical partition) of your architecture layers.
Software specifications
A prescriptive and technology oriented specifications of your solution.
I have presented on Enterprise Architecture a few times over the past couple of years. One of the quotes (from myself) that I use in my talks is: "Just because I am an Enterprise Architect, that does not mean that I am an Enterprise Architect". That might seem like a strange quote but it's basically just a fun way to say that enterprise architecture can mean different things to different organizations and people.
Enterprise architects tend to work across a broad domain of concerns, occasionally focusing on specific aspects of a specific technology and/or business process. Some organizations (they tend to be the ones with a more mature EA practice) will have architects that work across all domains within the organization (or, enterprise - hence enterprise architect). Some organizations will have specific types of architects (e.g. applications architect, solutions architect, data architect, network/systems architect, business architect, etc.) that focus on a particular area. Having various types of architects within an organization is one way to "ease" yourself into the architecture space.
For example, the organization I work for has the role, Lead Developer. Each development team has a lead developer and they essentially act as applications architects (even if that is not their specific title). For someone new to that role, they focus on learning the business domain their team is typically responsible for. They also provide the overall architectural vision and design for the apps their team produces. And, they also work closely with the enterprise architects to ensure they are working within the parameters of the organization as a whole (i.e. not reinventing the wheel or making use of a technology or approach that does not fit within the enterprise architecture as a whole).
Starting out as a lead developer is one way to get your foot in the door, so to speak. There are other ways. For example, if you're interested in data architecture, then joining a BI team would be a great way to learn more about data architecture at scale. Joining a network team would go a long way toward gaining knowledge that could be applied as a network/systems architect.
You mention TOGAF in your question above but there are many architectural frameworks out there (TOGAF, Zachman, DoDAF, etc.). Depending upon your specific situation, a "canned" framework might make sense for your organization and it might not. However, becoming familiar with some of the available frameworks will give you insights into some of the common challenges faced by enterprise architects. In the end, however, you will want to do what is right for your organization. You might take bits and pieces from multiple frameworks and wrap them all up into your own framework. As with many challenges, do what works for you.
Along with everything else, keep in mind that enterprise architects tend to think strategically and keep a focus on the future. That does not mean that they do not think tactically or are not concerned with the "here and now". They just tend to have strengths when it comes to strategy and vision.
While this is a bit of a wordy answer, the reality is that nothing beats experience. If you want to become an enterprise architect then you should try to apply architectural practices to your everyday tasks. The more you work and act like an enterprise architect the more ready you will be when an opportunity presents itself.
Hope this helps!
If you want to be a software architect - aka Application Architect, then TOGAF is useful to know, but not necessary for you. Enterprise architects deal with things that impact the entire organisation, particularly things like Strategy & Planning. Organisational modelling, etc.
They can be sometimes involved as a governance role to ensure alignment with organisational design standards, or security standards. They can also sometimes be involved in setting organisational policy.
Either way - too many people assuming taking the "most senior looking" title will get them the best pay and the best life - this is not always true and an EA role is very very different to a software architect - even though they are both "Architects"
Now getting a solid understanding of Enterprise Archtiecture will be a challenge - because 1. its kind of undefined right now - or more accurately - there is around 460+ different models of what an Enterprise Architecture is - TOGAF only being one of them. 2. Most EAs like to get completely OCD around model definitions, and each one has a different OCD point of view exactly what they are - I should know, I'm one of them :)
One of the best general models I have found is DoDAF, but it sure isn't light bedtime reading. Wikipedia has a reasonably light definition though and it might be worth starting there if you haven't already
Enterprise Architecture (EA) entails the whole organization and possibly beyond. It includes Business Architecture, Information Architecture, Technology Architecture & Application Architecture. EA is strategic and thus it is "What" needs to be done.
Our client has a requirement to re-design from scratch a product in an Enterprise Architecture Business Domain. The product has an ability to model business processes, information, technology, infrastructure, data etc. for the entire organization of the end user with the help of standard E.A. Framework methods & tools like BPM/N, TOGAF, ArchiMate, etc.
There are many abstract (meta) modelling concepts which enables the product to also integrate with multiple third-party systems e.g. ERP, CRM, Project Management, Financial Management & Service Delivery systems of the end-customers for data synchronization purpose.
The question - Is Domain-Driven Design a right fit for modeling the core domain of this kind of product?
I recommend reading the books "Domain-Driven Design" of Eric Evans and "Implementing Domain-Driven Design" of Vaughn Vernon. The first thing to realize is NOT to build the ONE big model that rules them all. DDD is about domains (one of which is the core domain) and subdomains. And it is about bounded contexts which could be connected in a variety of ways described in the books. So basically you will end up with a lot of autonomous subsystems with seemingly redundant data, that communicate with each other in an loosely coupled way and synchronize part of their data with loosely coupled communication. Much overarching constraints will be only eventually consistent and system, processes and users must tolerate this.
So in a landscape of the complexity you describe I think YES. DDD is a right fit for possibly several core domains of several systems. But feel free to use simpler methods in subsystems that are pure crud and data centric.
The Enterprise Architecture project will provide a layered model of your business... it will precise all the componentized parts of your domain : actors, departments, services, functions... If your goal is to align the solution on the domain (as I suppose), I think Domain Driven Development is a very good fit for what you are trying to achieve. Basically, EA can show you how your solution should look like. As DDD is all about "specialization", rather than "reuse" or "generalization", you should be careful on not depending on Legacy Services that could break your Bounded Contexts (in DDD, for instance, Business Rules implementations should remain in the BC they serve, and not being scattered in the whole solution across external dependencies...). EA is a wonderful tool to define Ubiquitous Language, Bounded Context boundaries. DDD is great at designing Services boundaries. EA will provide strategic tools that will help you designing the BCs. As DDD, SOA, EA share many common first-citizen principles, they will fit very well.
My contribution comes late, have you some experience to share with us ?
a) Do Core Domain and Generic Subdomain ( GS ) in most cases contain different parts of the same domain model or does each GS define its own domain model, which is usually different from the model used in Core Domain?
b) If the former, then I assume the reason for both using the same model is because the primary purpose of GS is to "serve" a Core Domain, and GS can "serve" best if there's no need for a translation layer between the Core Domain and GS ( if each used its own model, then we'd also need a translation layer between the GS and Core Domain )?
thanks
Core Domains, Supporting Subdomains and Generic Subdomains evolve around the concept of the Bounded Context in DDD.
To answer your question, the Core Domain is the domain which makes your business unique and gives you an advantage over your competitors - you will put most efforts (developers/monry) into improving it. A Generic Subdomain handles a topic that is still important but there is a chance you'll find an existing solution (either as a concept or reusable code) that handles the tasks good enough.
The Generic Subdomain would have a different model because it tackles a different domain.
A Generic Subdomain may describe anything from date/time(zone) handling see (2, Ch. 15), persistence, the user-interface toolkit up to a mail server or a complete inventory management system (1, Ch. 2). On the other hand, the inventory management logic is the Core Domain of the inventory management system's vendor.
You can find in-depth information in the book Implementing Domain-Driven Design and of course in the original book introducing Domain-Driven Design by Eric Evans.
Update: (see comment)
In my opinion, the most important aspect in Core Domains using any kind of Subdomain is not to overthink this topic on an abstract level. You'll probably agree that the biggest challenge in Domain-Driven Design is to find good examples that, by plan or accidentally, match the patterns/strategies from the Strategic Design section of the Domain-Driven Design book.
Now, from my understanding, the need for a translation layer between Core Domain and Generic Subdomains arises simply from necessity. In Chapter 15, Distillation of Domain-Driven Design four options on how to develop Generic Subdomains are discussed with their corresponding pros and cons:
An Off-the-Shelf Solution
A Published Design or Model
An Outsourced Implementation
An In-House Implementation
I won't repeat the discussion because this would just include quoting from the excellent book. You'll probably agree that a custom tailored and well-designed in-house solution, that is only used for this project, does not need a translation layer. On the other hand, a commercial or open-source Off-the-Shelf Solution is more likely to require an abstraction because you have little control on how the product evolves, if it has an appropriate Intention-Revealing Interface and so on.
There are two other aspects that are related but should not be mixed up with Subdomains:
Communication between Bounded Contexts
Cohesive Mechanisms
Bounded Contexts need some kind of translation by sheer definition. For each Bounded Context, there is a Model in Context. A Context Map documents the relationships and interactions of Bounded Contexts with Translation Map. The different ways of relating models of BoundedContexts are discussed in Chapter 14, Mainting Model Integrity (Anti-Corruption Layer, Open-Host Service and others).
Cohesive Mechanisms (see Chapter 15 of Domain-Driven Design), on the other hand, are similar to Generic Subdomains as both are introduced to relieve the Core Domain from unnecessary clutter. Eric Evans describes Cohesive Mechanisms as a lightweight framework but admits that in practice the distinction between Cohesive Mechanisms and Generic Subdomains is mostly not pure.
I'd like to say that I had to read those sections again as I do not deal with this on a daily basis so please be forgiving. Additionally, I am not in the inner circle of the DDD community and thus I am not aware if these issues are evaluated differently today. They still seem very useful to me and I have not encountered a better set of tools in this area so I assume they are still valid.
I understand the urge to understand these concepts but a real understanding can only be achieved by looking at concrete examples. Some are mentioned in the books. None of them are claimed perfect. The understanding and assessment of these complex problems, large or small, changes over time and this the soul of DDD in my opinion.
Can somebody please explain (in succinct terms) what exactly is domain driven design? I see the term quite a lot but really don't understand what it is or what it looks like. How does it differ from non-domain driven design?
Also, can somebody explain what a Domain Object is? How does domain differ from normal objects?
EDIT:
As this seem to be a top result on Google and my answer below is not, please refer to this much better answer:
https://stackoverflow.com/a/1222488/1240557
OLD ANSWER (not so complete :))
In order to create good software, you have to know what that software
is all about. You cannot create a banking software system unless you
have a good understanding of what banking is all about, one must
understand the domain of banking.
From: Domain Driven Design by Eric Evans.
This book does a pretty good job of describing DDD.
Register to download a summary of the book.
Domain Driven Design is a methodology and process prescription for the development of complex systems whose focus is mapping activities, tasks, events, and data within a problem domain into the technology artifacts of a solution domain.
The emphasis of Domain Driven Design is to understand the problem domain in order to create an abstract model of the problem domain which can then be implemented in a particular set of technologies. Domain Driven Design as a methodology provides guidelines for how this model development and technology development can result in a system that meets the needs of the people using it while also being robust in the face of change in the problem domain.
The process side of Domain Driven Design involves the collaboration between domain experts, people who know the problem domain, and the design/architecture experts, people who know the solution domain. The idea is to have a shared model with shared language so that as people from these two different domains with their two different perspectives discuss the solution they are actually discussing a shared knowledge base with shared concepts.
The lack of a shared problem domain understanding between the people who need a particular system and the people who are designing and implementing the system seems to be a core impediment to successful projects. Domain Driven Design is a methodology to address this impediment.
It is more than having an object model. The focus is really about the shared communication and improving collaboration so that the actual needs within the problem domain can be discovered and an appropriate solution created to meet those needs.
Domain-Driven Design: The Good and The Challenging provides a brief overview with this comment:
DDD helps discover the top-level architecture and inform about the
mechanics and dynamics of the domain that the software needs to
replicate. Concretely, it means that a well done DDD analysis
minimizes misunderstandings between domain experts and software
architects, and it reduces the subsequent number of expensive requests
for change. By splitting the domain complexity in smaller contexts,
DDD avoids forcing project architects to design a bloated object
model, which is where a lot of time is lost in working out
implementation details — in part because the number of entities to
deal with often grows beyond the size of conference-room white boards.
Also see this article Domain Driven Design for Services Architecture which provides a short example. The article provides the following thumbnail description of Domain Driven Design.
Domain Driven Design advocates modeling based on the reality of
business as relevant to our use cases. As it is now getting older and
hype level decreasing, many of us forget that the DDD approach really
helps in understanding the problem at hand and design software towards
the common understanding of the solution. When building applications,
DDD talks about problems as domains and subdomains. It describes
independent steps/areas of problems as bounded contexts, emphasizes a
common language to talk about these problems, and adds many technical
concepts, like entities, value objects and aggregate root rules to
support the implementation.
Martin Fowler has written a number of articles in which Domain Driven Design as a methodology is mentioned. For instance this article, BoundedContext, provides an overview of the bounded context concept from Domain Driven Development.
In those younger days we were advised to build a unified model of the
entire business, but DDD recognizes that we've learned that "total
unification of the domain model for a large system will not be
feasible or cost-effective" 1. So instead DDD divides up a large
system into Bounded Contexts, each of which can have a unified model -
essentially a way of structuring MultipleCanonicalModels.
You CAN ONLY understand Domain driven design by first comprehending what the following are:
What is a domain?
The field for which a system is built. Airport management, insurance sales, coffee shops, orbital flight, you name it.
It's not unusual for an application to span several different domains. For example, an online retail system might be working in the domains of shipping (picking appropriate ways to deliver, depending on items and destination), pricing (including promotions and user-specific pricing by, say, location), and recommendations (calculating related products by purchase history).
What is a model?
"A useful approximation to the problem at hand." -- Gerry Sussman
An Employee class is not a real employee. It models a real employee. We know that the model does not capture everything about real employees, and that's not the point of it. It's only meant to capture what we are interested in for the current context.
Different domains may be interested in different ways to model the same thing. For example, the salary department and the human resources department may model employees in different ways.
What is a domain model?
A model for a domain.
What is Domain-Driven Design (DDD)?
It is a development approach that deeply values the domain model and connects it to the implementation. DDD was coined and initially developed by Eric Evans.
Culled from here
Here is another good article that you may check out on Domain Driven Design. if your application is anything serious than college assignment. The basic premise is structure everything around your entities and have a strong domain model. Differentiate between services that provide infrastructure related things (like sending email, persisting data) and services that actually do things that are your core business requirments.
Hope that helps.
As in TDD & BDD you/ team focus the most on test and behavior of the system than code implementation.
Similar way when system analyst, product owner, development team and ofcourse the code - entities/ classes, variables, functions, user interfaces processes communicate using the same language, its called Domain Driven Design
DDD is a thought process. When modeling a design of software you need to keep business domain/process in the center of attention rather than data structures, data flows, technology, internal and external dependencies.
There are many approaches to model systerm using DDD
event sourcing (using events as a single source of truth)
relational databases
graph databases
using functional languages
Domain object:
In very naive words, an object which
has name based on business process/flow
has complete control on its internal state i.e exposes methods to manipulate state.
always fulfill all business invariants/business rules in context of its use.
follows single responsibility principle
DDD(domain driven design) is a useful concept for analyse of requirements of a project and handling the complexity of these requirements.Before that people were analysing these requirements with considering the relationships between classes and tables and in fact their design were based on database tables relationships it is not old but it has some problems:
In big projects with complex requirements it is not useful although this is a great way of design for small projects.
when you are dealing with none technical persons that they don,t have technical concept, this conflict may cause some huge problems in our project.
So DDD handle the first problem with considering the main project as a Domain and splitting each part of this project to small pieces which we are famous to Bounded Context and each of them do not have any influence on other pieces.
And the second problem has been solved with a ubiquitous language which is a common language between technical team members and Product owners which are not technical but have enough knowledge about their requirements
Generally the simple definition for Domain is the main project that makes money for the owners and other teams.
I do not want to repeat others' answers, so, in short I explain some common misunderstanding
Practical resource: PATTERNS, PRINCIPLES, AND PRACTICES OF DOMAIN-DRIVEN DESIGN by Scott Millett
It is a methodology for complicated business systems. It takes all the technical matters out when communicating with business experts
It provides an extensive understanding of (simplified and distilled model of) business across the whole dev team.
it keeps business model in sync with code model by using ubiquitous language (the language understood by the whole dev team, business experts, business analysts, ...), which is used for communication within the dev team or dev with other teams
It has nothing to do with Project Management. Although it can be perfectly used in project management methods like Agile.
You should avoid using it all across your project
DDD stresses the need to focus the most effort on the core subdomain. The core subdomain is the
area of your product that will be the difference between it being a success and it being a failure. It’s
the product’s unique selling point, the reason it is being built rather than bought.
Basically, it is because it takes too much time and effort. So, it is suggested to break down the whole domain into subdomain and just apply it in those with high business value. (ex not in generic subdomain like email, ...)
It is not object oriented programming. It is mostly problem solving approach and (sometimes) you do not need to use OO patterns (such as Gang of Four) in your domain models. Simply because it can not be understood by Business Experts (they do not know much about Factory, Decorator, ...). There are even some patterns in DDD (such as The Transaction Script, Table Module) which are not 100% in line with OO concepts.
I believe the following pdf will give you the bigger picture. Domain Driven Design by Eric Evans
NOTE: Think of a project you can work on, apply the little things you understood and see best practices. It will help you to grow your ability to the micro service architecture design approach too.
Get an organization wide understanding of the problem domain by
developing a ubiquitous language (a common mental model) per sub-problem-domain.
Use that language as close as possible in solution domains (code).
Only then choose technologies.
Don't be technology driven but problem domain or business driven.
This is one thing that has been bugging me for a while about DDD. I can clearly see the benefits of the approach when dealing with non-technical business domains with complex models and lots of interaction required between technical people and non-technical domain experts.
However, what about when the 'domain' in question is technical?
For instance, situation A) take a web start-up. Imagine they are trying to accomplish something quite complicated (say a facebook clone), but almost all of the staff are technical (or at least have strong technical understanding).
What about situation B) A similar situation, but with a slightly less ambitious project, and a lone developer trying to create somthing with an elegant architecture.
I'd be really interested to hear what people have to say. What I'm really trying to get to the meat of, is where the benefits of DDD lie, what the downsides might are, and at what point one outweighs the other...
DDD is really just an elaboration of the design pattern Fowler calls Domain Model in Patterns of Enterprise Application Architecture. In that book, he compares Domain Model to other ways of organizing code, such as Transaction Script, but it is clear that he prefers Domain Model over other alternatives for all but the simplest of applications. I do, too.
DDD simply expands greatly on the original concept of a Domain Model and provides tons of guidance on how we should analyze and model our domain in a way that will be beneficial to ourselves as developers.
If the Domain in question is complex, then a Domain model (and hence DDD) is a good choice. It doesn't really matter whether the Domain is business-oriented or more technical in nature. In his book Domain-Driven Design, Eric Evans starts by describing how the DDD techniques helped him model a Printed Circuit Board application. That is surely a technical Domain, if any!
In my current work, we are using DDD to model an application that deals with Claims-based identity - another very technical Domain.
DDD is really just about dealing with complexity in sofware, and this is also the subtitle of Evans' book: "Tackling Complexity in the Heart of Software."
Evans suggest using Domain Driven Design when :
Domain Complexity > Technical Complexity
If your domain is simple but you have many technical limitations (technology choice, performance restrictions etc), do not use DDD.
If your domain in complex, do DDD, put the domain as the core of your system, and move any other concern outside (persistence, performance, technology concerns).
I don't really have a great answer for you, but I can say from my perspective as an outsider to DDD with an interest in DDD I've seen technical domain concepts / drivers creep into the the DDD conversation as first class concepts. A good example of this would be that some people are advocating for technical / infrastructure bounded contexts. The best example I can think of is Greg Young's architecture where he considers reads a bounded context and transactional writes another bounded context. In general I think things like this are "domain constructs" (my term... forgive me if I must mutilated a real DDD term). It's similiar to objects in the OO world that don't model something in the real world but are fully flushed out objects.