How is the best way to design the following domain

Question

Ok, so... I have an entity called Lead, then when I instantiate this entity, it should look for an entity called Account, associating themselves by the property account_id. A Lead matches with an Account by two properties in Lead the areacode and campaign_id. How can I design this to create a nice object orientation?

1. A method matchAccount in Lead?
2. A method intakeLead in AccountsController/AccountAggregator?
3. An another class AccountMatcher to deal with it?
4. None of them. I suggest...

Thanks!

Answer 1

With DDD, it's all about the domain concepts and relationships (which are NOT rdbms relationships). OOP doesn't mater either, as it's a technical approach while you're using a business (domain) approach. However, you'll be using OOP implicitely because it's the nautral way to model a domain.

I don't know your domain, but based on how you described the problem, I think there is not much DDD there, but the old CRUD mindset masked by DDD terminology. IT doesn't look that you have identified the relevant bounded context and aggregate roots (AR). Then, what can those entities do (the behaviour)? How they are used (the uses cases they're involved)?

WHen you do DDD, you let the domain tell you which are the objects and how they interact with each other. An AR can 'point' to another AR via an Id, however the context and the use cases it matters a lot. And you can have multiple AR modelling the same concept but in different contexts, so there isn't always just one Account AR usable everywhere.

Take your time and forget about OOP, ORM, rdbms etc. Focus only on the Domain to properly understand the concepts (they can be tricky!) and their relationships. The resulting code will be good OOP and more importantly good modelling. Worry about persistence and rdbms after that.

Edit

Based on OP and the gist from the comment, I think (I can only guess since I don't now the domain) that it's a use case for Lead (Table) so, If there are no other relevant details, I'd have a service or similar which will take the Lead and IEnumerable to do the behaviour. You ask the Accounts repository for the accounts for the lead, providing a matching criteria (area code and campaign_id).

As a rule of thumb, I suggest to try and dissect these concepts and try to reformulate their relationships until you're certain you've understood the right relationship.

Answer 2

In a strict meaning of OOP, you should use associations in order to describe how objects are related each other.

If you express associations looking for them by a key using a method, in my opinion you're expressing objects using relational design principles, and this isn't object-oriented programming.

Actually I don't know if you're using an OR/M or not in order to persist such domain to some database, but if you're doing such way you should be able of creating actual associations and map them to tables in a way that your domain will be expressed as a full object-oriented programming design:

• Lead has a property called "Account" which associates 1 Lead to 1 account (1:1 association).

Furthermore, OOP and OR/M, or just data-mappers, work better with artificial keys (single column keys) rather than composite ones.

Maybe you're not using an OR/M. Then, a simple solution would be adding a method in your classes that would load associations called "Load" without parameters:

Lead lead = new Lead();
lead.Load();

// Now you can access "Account" association:
lead.Account.Id

Obviously you can complicate this solution but you'll end up in your own OR/M, so you'll be better if you don't reinvent the wheel and you take advantage of any of existing ones!