DDD - What is a complex domain?

Question

It is often said that DDD (Domain-driven Design) best applies to complex domains.

• What characterizes a complex domain? (please be more specific than "it has complex business rules").

• What would be examples of complex domains?

• How can I classify a domain as complex (ie appropriate for DDD) or not?

That other question didn’t seem enough to answer that. The current question would be a complement to it.

This question has a version in English; Let’s see what people are up to there.

Answer 1

Yoda type response (because it will probably not exhaust the subject...)

1. A complex domain is basically a set of knowledge with which the system will have to deal, granulate and make available, through its various resources. A simple example:

2.1 (simple domain) a seller issues an order and sends it to the rear (in this scenario, the domain would be simple, I don’t need to know much, I don’t need to get much and I don’t need to make many things available to the rear...)

2.2 (complex domain) the seller issues the order, considering a promotion for SOME items of that order (the other items have no promotion), other items have bonus, (i.e., the customer buys 1 product, wins another, buys quantity x of one, wins another...); the seller, upon closing the order, needs to know what final amount he will receive from commission. There is also a "current account" logic, in which, whenever the selling margin is better, a value is increased in the current account of the seller, and this account is viewable in the rear. Each seller has a ceiling for granting discounts, which is also observed for certain products (good profit margin) and customers (volume of purchases, duplicates on time, etc.). With this, the novice seller, selling a product with little profit margin to a new customer, would set a worse scenario to grant a discount. The stock of the product is also considered in this scenario. Therefore, if the customer requests 10 units of a product and only 3 will be delivered, it will be necessary to generate an order with the balance, and already inform the customer beforehand about the delivery time of that order(an order for future delivery on the seller’s device and at the rear); if the customer thinks it will take too long, he already wants to decide whether to leave the order issued or not. At the moment the item is added, the quantity in stock must be indicated in it. In the rear it is possible to check if the seller visited the customer on the stipulated date; if the customer was visited, and was not positive (not bought), the seller must fill out a justification. If the seller has not obeyed the route of visits for some reason, this will be made clear through the rear reports.

3. To determine whether a domain will be complex, try to answer these questions:

3.1 what level of granularity will be set aside in the requirements?

3.2 of all that has been raised through requirements, how much will I need to make available through the resources that will be developed? (Mobile App, Web API, Iot, etc...)

• Take courage and read the evans' book whole. If a book can form a neurosurgeon, it can form a programmer. It is one thing to have to deliver the project soon, abstracting some things superficially in order to solve some problem punctually. Another is, after delivering the project, the feeling that you don’t need to read about it, because you already delivered the solution. We can call it self-sabotage (one day, that knowledge will be missed). If you do not have time to do a thorough reading during development, read it as soon as you can. In the next "shooting" you will have some advantages.

• Who studies design patterns, SCRUM, Kanban, S.O.L.I.D., DDD, TDD and things like that, sometimes suffers from "patternite" (term I met with the Fabio Margarito; that is, when the programmer wants to use standard in everything). The fact of being able does not prevent us from being pragmatic, whenever possible.

• What we need to understand in the DDD is: our coding capability is an accessory to the solution that will be proposed. As Evans says in the book, every new domain, that subject to be part of us. It is this ability to get involved with the questions/pains of the client that seems that the staff is not very keen, but this is the talk. To solve the customer problem, I use his accent, his language, and model the code/solution according to the problem that the customer has transmitted(even if we only have a paper napkin)

Good luck!