Re: Massive stored proc data base operation to DDD
"Juan Labrada [email protected] [domaindrivendesign]" <[email protected]> Sat, 22 Nov 2014 08:39:41 -0800
| Newsgroups | gmane.comp.programming.domain-driven-design |
|---|---|
| Message-ID | <[email protected]> |
Hi Varghese, What do you need the classification for? If you are taking a DDD approach maybe you can define a Specification for vegetable and use it when the classification is needed. Regards Juan On Nov 22, 2014, at 6:31 AM, [email protected] [domaindrivendesign] <[email protected]> wrote: > > Lets take an example of a product classification. All the products needs to be classified as vegetable or not. This is a command which should take some time to complete because there are millions of products. This is a B2B scenario, so the agents do this operation quite often like few times every day. This is a UPDATE operation not a read operation. The business logic is, the product can be classified as vegetable if that product is from company A, B & C. If the product is not from those companies they are not vegetables. There are millions of products in the database with it's vendor. Approaching this from a data perspective, this can be done in a stored procedure with few lines of code. The operation may take only few seconds even if it is done synchronize. > > > > Now let me approach this from a DDD perspective. As I understand, the DDD goes against the idea of putting the logic in the stored procedure. The logic can be put as a behavior on product which can self classify based on who is the source, or the aggregate root can do that job. To do this, all the million products need to be read into memory from the database, process and then save it back to the database through the repository (whether it is SQL, Document based, mySql or whatever). > > > The problem here is the large amount of memory this operation needs when done using the DDD approach. If the operation is done in chucks like 50,000 the repository has to first figure out how may products needs to be classified and the domain has to plan the long running operation in chunks. Surely, this approach is going to take more time and a bad user experience for the user who has to wait more time than a process than a stored procedure takes. > > > > What is the reasonable approach to DDD when it comes to long running massive data processes? Is the delay expected, so the app has to inform the user that the classification is going to take time like 5 minutes or so and will let the user know when that is complete? And should not use stored procedure to have the classification logic, but have the business logic as part of the domain. > > > > You can think about the classification business logic which can change in the future. In this example, it is based on the vendor who provides the product. That can change to country. For example, all the products come from Country A will be wine. There is a greater flexibility with having this logic as part of the domain. But what worries me is the large amount of memory this operation has to take. > > > > Appreciate feedback from DDD gurus. > > > > > > >