DDD - What is a complex domain?

6

Domain-driven Design (DDD) is best applied 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 (that is, suitable for DDD) or not?

This other question did not 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 the staff responds to.

    
asked by anonymous 19.01.2016 / 13:18

1 answer

3

Yoda Master Answer (because it probably will not exhaust the subject ...)

  • A complex domain is basically a set of knowledge that the system will have to deal with, granular and make available through its various resources. A simple example:
  • 2.1 (simple domain) A salesperson issues a request and sends it to the rear (in this scenario, the domain would be simple, I do not need to know much, I do not need to get much and do not 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 (other items are not promoted), other items have a bonus, (ie the customer buys 1 product, wins another, buys quantity x of one, wins another ...); the seller, when closing the order, needs to know the final amount he will receive in commission. There is also a logic of "checking account", where, whenever the margin of sale is better, a value is incremented in the current account of the seller, and this account can be viewed at the rear. Each seller has a maximum limit for granting discounts, which is also observed for certain products (good profit margin) and customers (volume of purchases, duplicates in day, etc.). As a result, the novice vendor, selling a low-profit product to a novice customer, would set the worst case scenario for a discount. The stock of the product is also considered in this scenario. Therefore, if the customer orders 10 units of a product and only 3 will be delivered, it will be necessary to generate an order with the balance, and to inform the customer in advance about the delivery deadline of that order (a request for future delivery in the seller's device and rear); if the client thinks it will take too long, he wants to decide whether to leave the request or not. At the moment the item is added, the quantity in stock should be indicated on it. At the rear it is possible to check if the seller visited the customer by the stipulated date; if the customer was visited, and was not positivado (not bought), the seller should fill out a justification. If the seller did not obey the visitation itinerary for some reason, this will be made clear through the backlog.

  • To determine if a domain will be complex, try answering these questions:
  • 3.1 What level of granularity will be elicited in the requirements?

    3.2 of everything that was 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 #. If a book can form a neuro surgeon can form a programmer. It is one thing to have to deliver the project soon, to abstract some things superficially so that you can solve some problem on time. Another is, after the project has been delivered, the feeling that you do not need to read about it, because you have already delivered the solution. We can call it self sabotage (one day, that knowledge will be lacking). If you do not have time to do an in-depth 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, SOLID, DDD, TDD and the like, sometimes suffer from patternite (a term I met with Fabio Margarito , that is, when the programmer wants to use default at all). The fact that we are trained does not prevent us from being pragmatic whenever possible.

    • What we need to understand in DDD is: our coding capability is an accessory to the solution that will be proposed. As Evans says in the book, with each new domain, that subject to be part of us. It is this ability to get involved with the client's issues / pains that it seems that the staff is not much to end, 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 client has transmitted (even if we only have a paper napkin).

    • >

    Good luck!

        
    20.01.2016 / 22:10