The last Pioneer Plot posed this question:
Congratulations! You are developing a domain model layer. Assuming your UI will send you dumb data transfer objects, how will your application layer consume it such that the business logic in your entities, value objects, aggregates, and so forth is not completely by-passed by blind mapping from DTOs to domain objects?
My answer
Yes, I have made a sudden reappearance, much to the chagrin of my foes, both domestically and internationally. We are not at Full Throttle, not at all, and the armory will be at half capacity for the foreseeable future.
However, we will continue with short posts on design problems I have faced recently as I take the reigns of a tech lead on a new agile team. It is a feature I just invented, and I think I’ll call it Pioneer Plot.
I left you with a simple problem: an entity, Step, has a StepOwner, which could be one of two implementations – a Client or the System itself. The behavior of the system is dependent on the instanceof StepOwner.
My answer
Not only is the EIP armory at half capacity, but your host is also under the weather. Therefore I am enacting Cruise Control mode until further notice. For the record, I am done with HP laptops. Both laptops have or had fried motherboards.
For now, a short design problem for you: suppose a Step has a StepOwner. A StepOwner might be a Client or the System itself. Clients have IDs, names, and Accounts. If StepOwner is the System, then there is a set of systematic actions to take, otherwise, do nothing. What is the right design?
 |
Announcer: You’re reading the EIP web-ring. |
