Unshackle Your Domain
Recorded at:
- Share
-
- |
Read later
My Reading List
Bio
Greg Young is co-founder and CTO of IMIS, a stock market analytics firm. He has 10+ years of varied experience in computer science from embedded operating systems to business systems. You can often find Greg on experts-exchange.com where he runs the .NET section of the site. He is a frequent contributor to InfoQ.
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community. QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.
- Sections
- Enterprise Architecture
- Process & Practices
- Architecture & Design
- Development
- Topics
- Database
- Business Process Modeling
- Enterprise Architecture
- Events
- Financial Applications
- SOA
- Transactions Processing
- Performance & Scalability
- Architecture
- Business Process Management
- QCon San Francisco 2008
- Design
- Extreme Transaction Processing
- QCon
- Event Driven Architecture
Confirms my beliefs too.. but some Queries
by
Dinkar Gupta
I have one Question which I often face. This is regarding the usage of DTOs and Domain Entities & Aggregates. It is argued number of times that this conversion of DTOs to Domain and Domain to DTO is an unnecessary overhead and also results in duplication of code and effort. My facades receives a DTO which is then mapped to a domain object (may by a domain object builder/mapper) and supplied to the Domain class for processing. Reverse happens when the domain object is supplied by the domain service that I invoked from the facade - I will use a DTOAssembler to assemble the DTO from domain object supplied.
Should one use the exposed domain object mechanism ? Maybe due to poorly designed models most of the time at least 70% of the DTOs are exact copies of the domain entities. That's where this model is questioned.
What's your view on that ?
Re: Confirms my beliefs too.. but some Queries
by
Vaughn Vernon
Re: Confirms my beliefs too.. but some Queries
by
Greg Young
I would suggest that you are losing an important piece of business information by sending DTOs up and down and just mapping them to domain objects. If you are finding that your models are not very different then maybe this is a place where you could be doing something simpler? Active record or various CRUD scaffolding systems come to mind.
Cheers,
Greg
Re: Confirms my beliefs too.. but some Queries
by
Dinkar Gupta
The problem was that the DTO's were always part of the data exchange contract between the client and the facades and carrying those over to data access layer seemed like coupling the data access and client requests. instead the model facades mapped the DTOs to what domain model accepted and the domain model objects were used by the DAL. But I do see the value in segregating the facades and underlying model in line with command query separation. I guess now the active records, value object model and scaffoldings (non transaction side) and domain model (transaction side) makes more sense. That is really some good advice and I am going to follow it.
Thanks for sharing.
Historic Modeling
by
Michael Perry
I've defined a set of rules and a framework for Historic Modeling:
Anti-Corruption Layer between Command and Query DBs
by
Michael Paterson
My team and I are in the process of designing a message oriented architecture much like the one you described. In fact we took quite a few ideas from you! You mentioned an anti-corruption layer between your Command and Query handlers / databases. Where does that live? I was considering a separate handler that would be triggered after the command handler did its business as we may not have full control over our databases...
Thoughts?
Thanks,
Mike
Re: Anti-Corruption Layer between Command and Query DBs
by
Greg Young
Sorry for the delay, I did not have email updates on, someone happened by here and sent me an email letting me know you had a question (thanks anonymous person).
Here is the general flow for me ...
UI sources a command ... pushes to domain.
Domain receives the command, maps to a command handler (aka application service, though in some cases you can map directly to aggregates)
Command handler maps the data in the command to a call on an aggregate root.
Aggregate root if the command succeeds stores events representing the changes that occured fromt he command.
When the aggregate root is saved to the repository the events are published.
That is the end of the life cycle within this bounded context (and the events go to say a bus). On the other end we now have a receiver (this is where the anti-corruption layer exists). As an example consider a ordering bc and a shipping bc ... the shipping bc is subscribed to events from the ordering bc, when it receives the events it takes the command, maps it to its own command handler and uses the event to create a parallel model of the ordering bc (in other words how "it views" the data of the ordering BC.
There are lots of reasons why this is a good thing to be doing availability, scalability, and the ability to host servers in varying locales all come to mind (for more see Pat Helland "Normalization is for sissies" which is a great paper on the subject).
HTH
Greg
Model changes affecting the audit trail?
by
Marc Grue
Re: Model changes affecting the audit trail?
by
Alex Cruise
In any case, I'd imagine that such structural changes need to go into the audit log too, with a monotonically increasing "generation count" assigned to each successive migration. Of course, for another layer of sanity checking, you'd probably want to attach the id of the generation that was current as of the time of the change to every audit record too.
And declarative migrations bring up all kinds of entertaining metamodel issues!
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think