50

I am diving in the domain driven design (DDD) and while I go more deeply in it there are some things that I don't get. As I understand it, a main point is to split the Domain Logic (Business Logic) from the Infrastructure (DB, File System, etc.).

What I am wondering is, what happens when I have very complex queries like a Material Resource Calculation Query? In that kind of query you work with heavy set operations, the kind of thing that SQL was designed for. Doing those calculations inside the Domain Layer and working with a lot of sets in it is like throwing away the SQL technology.

Doing these calculations in the infrastructure can't happen too, because the DDD pattern allows for changes in the infrastructure without changing the Domain Layer and knowing that MongoDB doesn't have the same capabilities of e.g. SQL Server, that can't happen.

Is that a pitfall of the DDD pattern?

Freiheit
  • 1,020
  • 8
  • 16
Leonardo Mangano
  • 654
  • 1
  • 5
  • 10
  • 37
    While SQL is designed to handle relational set algebra, it is not a fun day when you realize that half of your business logic is buried in a handful of SQL functions that are hard to refactor and even harder to test. So, moving this to the domain layer where it can play with its friends sounds appealing to me. Is this throwing away a good chunk of the SQL technology? Sure, but SQL is a lot easier to manage when you're only using SELECT/JOIN. – Jared Goguen Apr 08 '19 at 13:13
  • 31
    @JaredGoguen but this can be because your not an SQL expert and not because of the technology – Leonardo Mangano Apr 08 '19 at 13:17
  • Related: https://softwareengineering.stackexchange.com/q/170808/20756 – Blrfl Apr 08 '19 at 13:19
  • I'm not sure what you mean by "can't happen" in the last part or why allowed changes in the infrastructure is a barrier, if that's what you are saying. – JimmyJames Apr 08 '19 at 13:35
  • 2
    @JimmyJames what I tried to say is that if the DDD is well implemented it allows to change layers with the minimum effort, like switching from SQL Server to MongoDB. But, if have complex queries in the SQL, it's possible that I won't be able to switch to MongoDB because their technical differences. I think I said a obvious thing. – Leonardo Mangano Apr 08 '19 at 13:52
  • 1
    @LeonardoMangano it can also exist only because the last person to work on it was only expert in SQL . Master many things. Let nothing be your master. – candied_orange Apr 08 '19 at 17:47
  • 8
    `... is like throwing away the SQL technology` Just because a particular technology *can* do something doesn't mean it is the best choice. It's anecdotal evidence, but I've met far too many businesses that used to store business logic in the database and are migrating away from it because of the long term maintainability headaches it causes. Oversimplifying, but databases are meant for storing data and programming languages are meant for transforming data. I wouldn't want to use a DB for business logic anymore than I'd want to try to use my application to store my data directly. – Conor Mancone Apr 08 '19 at 20:23
  • 8
    SQL itself is a great example of DDD. When faced with organizing related data people first specified a language to do it: SQL. Implementation does not really matter much. A DB admin does not need to know C/C++ to query the database. Similarly when faced with the task of scheduling events someone came up with the CRON syntax (m h d m w) a simple domain model that fits 99% of scheduling problems. The core of DDD is not to create classes or tables etc. It is to understand your problem and come up with a system to work in your problem domain – slebetman Apr 09 '19 at 08:33
  • Isn't DDD about design (as opposed to implementation)? Therefore, it doesn't preclude the use of SQL for implementing the design. – RWRkeSBZ Apr 09 '19 at 21:57
  • 1
    @ConorMancone, it is false to say databases are meant only for storing data. That is not only what actual database software is designed for. Also, the maintainability headache is not necessarily resolved either by using two systems or two different languages - it possibly merely converts one headache to another. – Steve May 29 '19 at 11:20
  • @Steve I don't disagree. Your comment is all hiding in my "oversimplifying" caveat. I.e., my statement wasn't meant to be 100% truth without exceptions. Certainly, a DB is best for storing data, and that is its primary use case. That doesn't mean it can't also do more when needed. It's also true that complicated systems are complicated, and no choice of technology can fix that. It's just a question of where you decide to hide the complexity (i.e. moving headaches around). You skip stored procedures but now you need ORMs and other complex tools to deal with the impedance mismatch. – Conor Mancone May 29 '19 at 12:51
  • As a general rule of thumb though, I've found that keeping the database layer as simple as possible (in my case that means data storage and foreign key constraints but stopping short of stored procedures) is a good use of its capabilities, and works well for me and my team. – Conor Mancone May 29 '19 at 12:52
  • @ConorMancone, obviously I grant you that there is some judgment involved here. But databases are not designed merely for storing data, they are designed for *processing* data and to cope with many of the irreducible challenges that arise around that. There is no requirement that procedures be stored, they can be defined and issued from the client side. It seems incorrect to say the database engine should not be used for any data transformation, when that is a strength for which both the engine and the query language are designed. – Steve May 29 '19 at 13:52

8 Answers8

41

These days, you are likely to see reads (queries) handled differently than writes (commands). In a system with a complicated query, the query itself is unlikely to pass through the domain model (which is primarily responsible for maintaining the consistency of writes).

You are absolutely right that we should render unto SQL that which is SQL. So we'll design a data model optimized around the reads, and a query of that data model will usually take a code path that does not include the domain model (with the possible exception of some input validation -- ensuring that parameters in the query are reasonable).

VoiceOfUnreason
  • 32,131
  • 2
  • 42
  • 79
  • 16
    +1 Good answer, but you should give this concept its proper name, Command-Query Segregation. – Mike Apr 08 '19 at 14:19
  • 7
    @Mike Having completely different models for reading and writing is more like CQRS rather than CQS. – Andy Apr 08 '19 at 15:17
  • 3
    The "read model" is not the domain model (or part of it)? I am not an expert on CQRS, but I always thought the command model is quite different from the classic domain model, but not the read model. So maybe you can give an example for this? – Doc Brown Apr 08 '19 at 17:14
  • Took me too long to realize that High Performance Mark was calling attention to a typo. – VoiceOfUnreason Apr 10 '19 at 11:50
  • @DocBrown - here is my attempt to clarify for you --> https://cascadefaliure.vocumsineratio.com/2019/04/read-models-vs-write-models.html – VoiceOfUnreason Apr 11 '19 at 04:03
  • @VoiceOfUnreason: your effort appreciated, but AFAICS there is still no concrete example, only some rather theoretical discussion about the envisioned properties of read and write models. Honestly, I would really like to see a real-world example. – Doc Brown Apr 11 '19 at 05:44
  • Understood; I should be able to extend the theory with a demonstration some time in the next few days. – VoiceOfUnreason Apr 11 '19 at 05:48
  • ... moreover, posts like [this one](https://news.ycombinator.com/item?id=13339972) give me the impression the initial sentence in this answer is a rather ambitious vision, not a description of something really happen very often in real-life projects. I actually don't buy that "these days, everyone is doing CQRS now" - there may have been many attempts to do CQRS, but lots of them have failed. – Doc Brown Apr 11 '19 at 05:59
  • 1
    @DocBrown One example from a previous project was when we had to maintain a separate read model in Elasticsearch. The primary data storage was an SQL database, and the command model represented input from front-end. But the read model was an aggregate/document type structure maintained in ES for performance, search and closely mirroring the structure expected by front-end. Did that make sense? – Subhash May 31 '19 at 03:38
25

As I understand it, a main point is to split the Domain Logic (Business Logic) from the Infrastructure (DB, File System, etc.).

This is the foundation of the misunderstanding: the purpose of DDD isn't to separate things along a hard line like "this is in the SQL server, so must not be BL", the purpose of DDD is to separate domains and create barriers between them that allow the internals of a domain to be completely separate from the internals of another domain, and to define shared externals between them.

Don't think of "being in SQL" as the BL/DL barrier—that's not what it is. Instead, think of "this is the end of the internal domain" as the barrier.

Each domain should have external-facing API's that allow it to work with all the other domains: in the case of the data storage layer, it should have read/write (CRUD) actions for the data-objects it stores. This means SQL itself isn't really the barrier, the VIEW and PROCEDURE components are. You should never read directly from the table: that is the implementation detail DDD tells us that, as an external consumer, we should not worry about.

Consider your example:

What I am wondering is, what happens when I have very complex queries like a Material Resource Calculation Query? In that kind of query you work with heavy set operations, the kind of thing that SQL was designed for.

This is exactly what should be in SQL then, and it's not a violation of DDD. It's what we made DDD for. With that calculation in SQL, that becomes part of the BL/DL. What you would do is use a separate view / stored procedure / what-have-you, and keep the business logic separated from the data-layer, as that is your external API. In fact, your data-layer should be another DDD Domain Layer, where your data-layer has it's own abstractions to work with the other domain layers.

Doing these calculations in the infrastructure can't happen too, because the DDD pattern allows for changes in the infrastructure without changing the Domain Layer and knowing that MongoDB doesn't have the same capabilities of e.g. SQL Server, that can't happen.

That's another misunderstanding: it says implementation details internally can change without changing other domain layers. It doesn't say you can just replace a whole infrastructure piece.

Again, keep in mind, DDD is about hiding internals with well-defined external API's. Where those API's sit is a totally different question, and DDD doesn't define that. It simply defines that these API's exist, and should never change.

DDD isn't setup to allow you to ad-hoc replace MSSQL with MongoDB—those are two totally different infrastructure components.

Instead, let's use an analogy for what DDD defines: gas vs. electric cars. Both of the vehicles have two completely different methods for creating propulsion, but they have the same API's: an on/off, a throttle/brake, and wheels to propel the vehicle. DDD says that we should be able to replace the engine (gas or electric) in our car. It doesn't say we can replace the car with a motorcycle, and that's effectively what MSSQL → MongoDB is.

Der Kommissar
  • 421
  • 3
  • 11
  • 1
    Thanks for the explanation. For me is a very hard topic, everyone have a different point of view. The only thing I don't agree is the comparison between MSSQL(car) and MongoDB (motorcycle), for me the right comparison is that these are two different engines for the same car, but it's just a opinion. – Leonardo Mangano Apr 08 '19 at 15:03
  • 9
    @LeonardoMangano Ah, but they're not. MSSQL is a relational database, MongoDB is a document database. Yes, "database" describes both, but that's about as far as it goes. The read/write techniques are _completely_ different. Instead of MongoDB, you could use Postgre or MySQL as an alternative, and _that_ would be a valid comparison. – Der Kommissar Apr 08 '19 at 15:05
  • 3
    "You should never read directly from the table..." Madness. – jpmc26 Apr 09 '19 at 01:20
  • "You should never read directly from the table..." This is a rule that I've come to implement on my own after a decade of writing software that interfaces with databases and suffering through the early pain of trying to follow tutorials structured around popular design patterns. – Jeff Camera May 07 '19 at 12:28
  • @LuciferSam Aye. It makes it far easier to manage the separation between implementation details, and domain boundaries. One "object" in the domain might be represented by 5 tables, so we use a View to encapsulate that object. – Der Kommissar May 07 '19 at 13:25
  • @Der Kommissar. I like your answer, but I am a bit puzzled about your previous comment. Please correct me if I misunderstood. Are you implementing your domain objects as database views to query these instead of the tables? – Anytoe Jul 27 '19 at 10:21
19

If you've ever been on a project where the organization paying to host the application decides that the database layer licenses are too expensive, you'll appreciate the ease of which you can migrate your database/data storage. All things considered, while this does happen, it doesn't happen often.

You can get the best of both worlds so to speak. If you consider performing the complex functions in the database an optimization, then you can use an interface to inject an alternate implementation of the calculation. The problem is that you have to maintain logic in multiple locations.

Deviating from an architectural pattern

When you find yourself at odds with implementing a pattern purely, or deviating in some area, then you have a decision to make. A pattern is simply a templated way to do things to help organize your project. At this point take time to evaluate:

  • Is this the right pattern? (many times it is, but sometimes it's just a bad fit)
  • Should I deviate in this one way?
  • Just how far have I deviated so far?

You'll find that some architectural patterns are a good fit for 80-90% of your application, but not so much for the remaining bits. The occasional deviation from the prescribed pattern is useful for performance or logistical reasons.

However, if you find that your cumulative deviations amount to a good deal more than 20% of your application architecture, it's probably just a bad fit.

If you choose to keep going with the architecture, then do yourself a favor and document where and why you deviated from the prescribed way of doing things. When you get a new enthusiastic member on your team, you can point them to that documentation which includes the performance measurements, and justifications. That will reduce the likelihood of repeat requests to fix the "problem". That documentation will also help disincentivize rampant deviations.

Berin Loritsch
  • 45,784
  • 7
  • 87
  • 160
  • I would avoid the use of phrases like "is this the right pattern" in answers. It's hard enough to get people to be specific when they write their questions, and by your own admission "sometimes it's a bad fit," which suggests that no, it's not the right pattern. – Robert Harvey Apr 08 '19 at 14:49
  • @RobertHarvey, I've been in projects where the pattern used was just not right for the application, which caused it to fail certain quality metrics. It's certainly not the norm, but when that happens you have the hard decision to change architectures or keep shoehorning code into the app. The sooner you can determine the bad fit, the easier it is to fix. That's why I always include that thought while evaluating edge cases. Along with the last bullet, sometimes you don't realize how bad a fit it is until you see the accumulation of deviations. – Berin Loritsch Apr 09 '19 at 12:41
9

The set manipulation logic that SQL is good at can be integrated with DDD no problem.

Say for example I need to know some aggregate value, total count of product by type. Easy to run in sql, but slow if I load every product into memory and add them all up.

I simply introduce a new Domain object, 

ProductInventory
{
    ProductType
    TotalCount
    DateTimeTaken
}

and a method on my repository

ProductRepository
{
    List<ProductInventory> TakeInventory(DateTime asOfDate) {...}
}

Sure, maybe I am now relying on my DB having certain abilities. But I still technically have the separation and as long as the logic is simple, I can argue that it is not 'business logic'

Ewan
  • 70,664
  • 5
  • 76
  • 161
  • Well, so far I recall. Repositories are supposed to get `Query` as parameters too. `repository.find(query);`. I have read the same but with `Specs. That opens a door to leave `Query` as an abstraction and `QueryImpl` or the specific-query implementation to the infrastructure layer. – Laiv Apr 08 '19 at 14:19
  • 5
    oh god, I know some people do that but I think it's awful. You can view this kind of thing as a step down that road. But I think it can be taken with caution. – Ewan Apr 08 '19 at 14:23
  • `I know some people do that` some people are Pivotal and its framework. SpringFramework has a lot of this:-). Anyways, As @VoiceOfUnreason has suggested, the key around DDD is keeping the consistency of the writings. I'm unsure about forcing the design with domain models whom only purpose is querying or parametrizing queries. That could be approached out of the domain with data structures (pocos, pojos, dtos, row mappers, whatever). – Laiv Apr 08 '19 at 14:28
  • obviously we need some sort of inquisition to help those people back to sanity. But I'm sticking to my guns. The partial exposure of the datalayer is acceptable when it objectively makes for a better application, where what is or isn't a "Domain Object" is subjective – Ewan Apr 08 '19 at 14:35
  • @Ewan what kind of object will be ProductInventory, Entity? Value Object? or just a class – Leonardo Mangano Apr 08 '19 at 14:51
  • 1
    @LeonardoMangano depends on your application and implementation. The main thing to realise is that you can reinterpret your Domain to make it practicable. – Ewan Apr 08 '19 at 14:57
  • Sometimes the Query pattern works, most of the time it doss not. – Andy Apr 08 '19 at 15:20
3

One of the possible ways to solve this dilemma is to think of SQL as of an assembly language: you rarely, if at all, code directly in it, but where performance matters, you need to be able to understand the code produced by your C/C++/Golang/Rust compiler and maybe even write a tiny snippet in assembly, if you cannot change the code in you high level language to produce desired machine code.

Similarly, in realm of databases and SQL, various SQL libraries (some of which are ORM), e.g. SQLAlchemy and Django ORM for Python, LINQ for .NET, provide higher level abstractions yet use generated SQL code where possible to achieve performance. They also provide some portability as to the used DB, possibly having different performance, e.g. on Postgres and MySQL, due to some operations using some more optimal DB-specific SQL.

And just as with high level languages, it is critical to understand how SQL works, even if it is just to rearrange the queries done with above mentioned SQL libraries, to be able to achieve desired efficiency.

P.S. I would rather make this a comment but I do not have sufficient reputation for that.

Kyrylo Shpytsya
  • 41
  • 2
2

As usual, this is one of those things that depends on a number of factors. It's true that there's a lot that you can do with SQL. There are also challenges with using it and some practical limitations of relational databases.

As Jared Goguen notes in the comments, SQL can be very difficult to test and verify. The main factors that lead to this are that it can't (in general) be decomposed into components. In practice, a complex query must be considered in toto. Another complicating factor is that be behavior and correctness of SQL is highly dependent on the structure and content of your data. This means that testing all the possible scenarios (or even determining what they are) is often infeasible or impossible. Refactoring of SQL and modification of database structure is likewise problematic.

The other big factor that has lead to moving away from SQL is relational databases tend to only scale vertically. For example, when you build complex calculations in SQL to run in SQL Server, they are going to execute on the database. That means all of that work is using resources on the database. The more that you do in SQL, the more resources your database will need both in terms of memory and CPU. It's often less efficient to do these things on other systems but there's no practical limit to the number of additional machines you can add to such a solution. This approach is less expensive and more fault-tolerant than building a monster database server.

These issues may or may not apply to the problem at hand. If you are able to solve your problem with available database resources, maybe SQL is fine for your problem-space. You need to consider growth, however. It might be fine today but a few years down the road, the cost of adding additional resources may become a problem.

JimmyJames
  • 24,682
  • 2
  • 50
  • 92
  • Isn't the alternative to a monster database, simply a monstrous number and diversity of auxiliary systems? What resilience do the auxiliary systems have, if they all hang off the core system? And if the justification is simply the technological limitation of the core system, then this will often be a premature optimisation for most business systems. SQL can in general be written in a decoupled fashion, if deemed necessary. – Steve May 29 '19 at 11:39
  • @Steve I think where you've gone wrong here is assuming there must be a single core system that others 'hang off' of. – JimmyJames May 29 '19 at 13:39
  • @Steve To give an example, you can replace a systems entire database with a single no-SQL database (i'm not saying this is always the right choice, just that it can be done.) That database can then be stored across many systems, even geographic regions. Such a DB is not auxiliary, it's a wholesale replacement of the SQL DB. – JimmyJames May 29 '19 at 13:58
  • @JimmyJames, agreed, but when there isn't a core system, that can create its own problems analysing dependencies and maintaining data consistency. That's the reason for monoliths in the first place - they create a certain kind of simplicity, and therefore certain kinds of analysis and maintenance efficiencies. Non-monolithic solutions merely exchange some problems or costs for others. – Steve May 29 '19 at 13:59
  • @jmoreno Throwing resources at something in order to limp along with it is not what I would call good engineering: ["in order to handle the site’s massive data volume, and is running 9,000 instances of memcached in order to keep up with the number of transactions the database must serve."](https://gigaom.com/2011/07/07/facebook-trapped-in-mysql-fate-worse-than-death/) Do you consider the cost of your designs or do you assume someone will shell out money to make your personal preferences workable? – JimmyJames May 29 '19 at 14:04
  • @Steve I think you are missing the point. You can create a monolithic system without using SQL. There's nothing in my answer about microservices or related architectures. I'm simply talking about the design of databases. – JimmyJames May 29 '19 at 14:09
  • @JimmyJames, but then you lose all the possible advantages provided by SQL databases. If you write for a generic storage technology, then you employ the advantages of none, and bear the limitations of all. And if you think no storage technology has any advantage over another, then possibly your requirements are only very general and can be met by any approach - and if that's the case, why would you ever need to switch storage technology, when any will do? – Steve May 29 '19 at 14:12
  • @Steve "then you lose all the possible advantages provided by SQL databases": That's a pretty bold assertion. Care to back up this claim? What are all the possible advantages and why can't they be implemented in any other way? "if you think no storage technology has any advantage over another" I have no idea how this fits into the context of my answer which is all about the disadvantages of a certain approach to storage. – JimmyJames May 29 '19 at 14:17
  • @JimmyJames, I agree monoliths don't require SQL. Your argument seemed to be that SQL promotes monoliths. My original point was simply that any approach that tries to decouple the parts of a system, simply introduces its own kind of inefficiencies and complexities. Where you get separate machines to perform calculations on data, it must be very rare not to find that at least one is dependent on another being in working order (as well as communication infrastructure between), and usually one particular machine is deemed the master. – Steve May 29 '19 at 14:24
  • @JimmyJames, the advantages of a particular storage technology could be anything. And different advantages can be implemented in different ways. But there is often a matrix of advantages and disadvantages with different technologies that are incompatible with one another - a refusal to choose simply means you get no advantage at all from any, except the ability to switch to another (whose specific advantages you also cannot employ). – Steve May 29 '19 at 14:28
  • @Steve "Your argument seemed to be that SQL promotes monoliths." I don't know where you are getting this. What about my answer suggests that to you exactly? – JimmyJames May 29 '19 at 14:32
  • @Steve "the advantages of a particular storage technology could be anything. And different advantages can be implemented in different ways." Or in other words: "If you come to a fork in the road, take it." - *Yogi Berra* – JimmyJames May 29 '19 at 14:34
  • @JimmyJames, your use of "monster database server", and that SQL is "difficult to test and verify...decompose into components... refactor...[or] scale", and that the alternative is "less expensive and more fault-tolerant". Your description of the alternative as involving distributing work amongst multiple machines also lends itself to the impression that the first thing in question is a monolith - a single machine that performs all tasks. – Steve May 29 '19 at 14:42
  • @Steve "difficult to test and verify...decompose into components... refactor...[or] scale" These are development challenges. Decomposing code doesn't imply multiple systems e.g. breaking down a large function into smaller ones. "a single machine that performs all tasks" That's how SQL databases (at least historically) are designed to work. Do you disagree? – JimmyJames May 29 '19 at 14:51
  • @jmoreno I don't understand what your point is, I guess. I'm laying out why these other technologies exist and your comment is that 'facebook uses MySQL'. And? Are you arguing that something is incorrect in my answer? Please be specific. – JimmyJames May 29 '19 at 15:06
  • @jmoreno FWIW, Facebook announced they were developing their own NoSQL database a while back. – JimmyJames May 29 '19 at 15:19
  • on decomposition etc., I wasn't suggesting that you implied multiple machines for this aspect - you were addressing software not hardware in that paragraph. Moving on, you say "a 'single machine performs all tasks' is how SQL was designed to work historically". I agree that the original relational databases were designed for mainframes, but I wonder where you're going with that. – Steve May 29 '19 at 16:36
  • @Steve I didn't mention mainframes. "I wonder where you're going with that" the benefits of SQL are greatly diminished if you move away from a single machine. – JimmyJames May 29 '19 at 16:45
  • @Steve I should clarify, SQL as a language can be used with non-relational DBs. I'm using SQL here as shorthand for a relational DB which is maybe too loose. – JimmyJames May 29 '19 at 16:50
  • @Steve Probably a bigger issue is that the complexity and challenges of distributing a relational DB e.g. sharding are very high. For example, unlike a NoSQL (dynamo-style) cluster where additional nodes add fault-tolerance, each shard is an additional single point of failure. – JimmyJames May 29 '19 at 17:02
  • ah I see your point about distributed databases. Many of those don't guarantee transactional consistency, and are designed for requirements that don't need or expect real-time consistency - or they employ eventual consistency, but that approach makes reasoning about the state of the system more complex. Most systems that support business administration do benefit from consistency guarantees to simplify analysis, and business administration requirements are what relational databases were first designed and optimised for. – Steve May 29 '19 at 18:29
  • @Steve Don't get me wrong here, relational DBs are still useful and in a lot of ways are more sophisticated than the NoSQL (an unfortunate term) options. But there are tradeoffs and these other types of DBs are purposely simpler to allow for solving different sets of problems. If you have a basically flat schema anyway (the Facebook example is relevant) and your real problem is scale and resilience then choosing a DB that has a lot of features you don't need and doesn't have the ones you need is pretty questionable. – JimmyJames May 29 '19 at 19:30
  • agreed. Certainly a relational database needn't be used in all cases, but they are reasonable enough for most general purposes (including where scale or resilience is required). "Scale" problems that I've come across with relational DBs were down to obviously poor design in the first place (esp. pre-emptive attempts to create flexibility, like EAV designs, which imposed the very burdens of rework that it was supposed to forestall, or over-normalisation and a lack of forethought about how redundant data would eventually be removed for archive or disposal). – Steve May 29 '19 at 20:11
2

Is that a pitfall of the DDD pattern?

Let me first clear a few misconceptions.

DDD is not a pattern. And it doesn't really prescribe patterns.

The preface to Eric Evan's DDD book states:

Leading software designers have recognized domain modeling and design as critical topics for at least 20 years, yet surprisingly little has been written about what needs to be done or how to do it. Although it has never been formulated clearly, a philosophy has emerged as an undercurrent in the object community, a philosophy I call domain-driven design.

[...]

A feature common to the successes was a rich domain model that evolved through iterations of design and became part of the fabric of the project.

This book provides a framework for making design decisions and a technical vocabulary for discussing domain design. It is a synthesis of widely accepted best practices along with my own insights and experiences.

So, it's a way to approach software development and domain modeling, plus some technical vocabulary that supports those activities (a vocabulary that includes various concepts and patterns). It's also not something completely new.

Another thing to keep in mind is that a domain model is not the OO implementation of it that can be found in your system - that's just one way to express it, or to express some part of it. A domain model is the way you think about the problem you are trying to solve with the software. It's how you understand and perceive things, how you talk about them. It's conceptual. But not in some vague sense. It's deep and refined, and is a result of hard work and knowledge gathering. It is further refined and likely evolved over time, and it involves implementation considerations (some of which may constrain the model). It should be shared by all team members (and involved domain experts), and it should drive how you implement the system, so that the system closely reflects it.

Nothing about that is inherently pro- or anti-SQL, although OO developers are perhaps generally better at expressing the model in OO languages, and the expression of many domain concepts is better supported by OOP. But sometimes parts of the model must be expressed in a different paradigm.

What I am wondering is, what happens when I have very complex queries [...]?

Well, generally speaking there are two scenarios here.

In the first case, some aspect of a domain really requires a complex query, and perhaps that aspect is best expressed in the SQL/relational paradigm - so use the appropriate tool for the job. Reflect those aspects in your domain thinking and the language used in communicating concepts. If the domain is complex, perhaps this is a part of a subdomain with it's own bounded context.

The other scenario is that the perceived need to express something in SQL is a result of constrained thinking. If a person or a team has always been database oriented in their thinking, it may be difficult for them, just due to inertia, to see a different way of approaching things. This becomes a problem when the old way fails to meet the new needs, and requires some thinking out of the box. DDD, as an approach to design, is in part about ways to find your way out of that box by gathering and distilling the knowledge about the domain. But everybody seems to ignore that part of the book, and focuses on some of the technical vocabulary and patterns listed.

Filip Milovanović
  • 8,428
  • 1
  • 13
  • 20
0

Sequel became popular when memory were expensive, because relational data model provided possibility to normalise your data and effectively store it in the file system.

Now memory is relatively cheap, so we can skip normalisation and store in in the format we use it or even duplicate a lot of same data for sake of speed.

Consider database as simple IO device, which responsibility to store data in the file system - yes I know it is difficult to imagine it, because we wrote plenty of applications with important business logic written into SQL queries - but just try to imagine that SQL Server is just another printer.

Would you embedded PDF generator into printer driver or added a trigger which will print log page for every sales order printed out of our printer?

I assume the answer will be no, because we don't want that our application are coupled to the specific device type (not even talking about efficiency of such idea)

In 70's- 90's SQL database were efficient, now? - Not sure, in some scenarios asynchronous data query will returns required data faster than multiple joins in SQL query.

SQL wasn't designed for complicated queries, it were designed for storing data in efficient way and then provide interface/language to query stored data.

I would say building your application around relational data model with complicated queries is abuse of database engine. Of course database engine providers are happy when you tightly coupling your business to their product - they will be more than happy to provide more features which make this bound stronger.

Fabio
  • 3,086
  • 1
  • 17
  • 25
  • 1
    But I keep thinking that SQL is way better for set calculations than any other language. From my point of view. your example is upside down, using C# for very complex set operations with million of rows and joins involved is using the wrong tool, but I could be wrong. – Leonardo Mangano Apr 09 '19 at 21:13
  • @LeonardoMangano, some examples: with c# I can chunk millions of rows and calculate it in parallel, I can retrieve data asynchronously and execute calculations "in time" when data is returned, with c# I can do calculations with low memory usage by enumerating row by row. Having complex logic in the code will provide you plenty of options how to do calculations. – Fabio Apr 09 '19 at 21:37