域驱动设计和批处理

Question

Has the following structure:

1. Presentation Level:

   Web Interface, REST API and command prompt - all call only OrderService.

2. Application Layer:

    class OrderService { private $em; private $repository; private $calculator; public function __construct( \\Doctrine\\ORM\\EntityManagerInterface $em; ClientRepositoryInterface $repository, cumulativeDiscountCalculator $calculator } { $this->em = $em; $this->repository = $repository; $this->calculator = $calculator; } public function calculateCumulativeDiscount($id) { $this->em->beginTransaction(); try { $client = $this->repository->findClient(); $this->calculator->calculate($client); $this->em->flush(); $this->em->commit(); } catch (\\Exception $e) { $this->em->rollback(); throw $e; } } } 

3. Model layer:

    interface ClientInterface { public function setDiscount($discount); } interface ClientRepositoryInterface { public function findClient($id); public function findClientsByDataRange($from, $to); } class cumulativeDiscountCalculator { public function calculate(ClientInterface $client) { $client->setDiscount(mt_rand(1, 50)); } } 

4. Infrastructure Layer:

   PHP Doctrine 2 - implement ClientRepositoryInterface.

My task - perform calculation discounts for a collection of clients. (method ClientRepositoryInterface::findClientsByDataRange returns collection for processing)

The problem is that I need to handle up to 100,000 records. I know how to do this technically, but how to do it in terms of DDD? The following questions arise:

• Which layer to use for batch processing?
• How to collect the results of actions: errors, count successful clients, etc?
• Where to set transaction boundaries(every N clients - commit and begin a new transaction)?
• I have about 10-20 batch operations, it may make sense any structure to develop?

Answer 1

In my opinion you should consider the batch operation as part of your domain not just like some "trivial" operation aside. Write down the requirements and you will see that it requires some domain modelling too. Eg. you need to store basic data about every batch run (type, when, how many records processed, results, related errors etc), then you need to have the functionality to preview and schedule them (when, which batch run, re-run etc). You might want to have some tool to monitor them in terms of time or resources (how long takes every run, how much memory it takes, etc).

From what you mention above I can imagine classes like:

• BatchRunner
• BatchInterface
• ClientDiscountBatch { $scheduleDay, $scheduleTime }
• BatchResultEntity { $itemProcessed, $itemErrors, $maxMemory, $duration }
• BatchResultRepository
• ...

Then each of your batch operations will implement the BatchInterface and will be managed by BatchRunner and results will be persisted by BatchResultRepository etc.

All the operations will be using other Domain classes like you mentioned above eg. CumulativeDiscountCalculator.

In the terms of transaction boundaries you keep using the existing boundaries - eg. Aggregate root. After every iteration you increase the number of results or log an error.