as we know, repositories are responsible for data persistence and return raw data on queries.
the question is, how to implement a mapper to map data between raw object and a rich domain model?
in a rich domain model we have state and behaviors (invariant, value objects), nothing more.
how and where to implement a method to map data from raw object to rich domain model?
in a mapper ? that mapper should call a method on the entity to set state without checking invariants (as they are validated before and we are sure about invariants)?
Related
I am learning about DDD and I would like to say what is the correct way to implement DTO using DDD principles ?
In my onion architecture I implement a first DTO definition in presentation layer to map datas between RabbitMQViewModel(presentation layer) and RabbitMQModelsResultDTO (application layer).
And I implement a second DTO definition between application layer (RabbitMQModelsResultDTO) and domain layer (entity LogRabbitMQ).
However, I am not sure if it's a good way to implement two DTO definition ?
Light description of my DTO definition in
presentation layer :
CreateMap<RabbitMQViewModel, RabbitMQModelsResultDTO>().ReverseMap();
and application layer :
CreateMap<Domain.Entities.LogRabbitMQ, RabbitMQModelsDTO>().ReverseMap();
It's a screen of my project architecture :
Translating presentation object (RabbitMQViewModel) into application object (RabbitMQModelsResultDTO) then application object into domain object (LogRabbitMQ) is considered to be a good practice in the DDD world.
However, it is pointless to make anemic, flat translations: it would be much easier to use the same object through all three layers (in which case DDD becomes irrelevant).
Here is how it can be done in the DDD way:
Application object reflects domain context properties, namely value objects, into which presentation object's primitives are translated.
Domain object is a "smart" object, implemented with all OOP goodies in order to keep it consistent all the time, and this object is being constructed using application object's properties.
As for the term "DTO", it should be used primarily for presentation object. It is less appropriate to use it in the context of application/domain objects, which are considered to be business objects.
I am trying to clarify my understanding of a DTO and an Entity object. It seems like an Entity can hold it's identity even if its attributes change as long as it has an id.
Isn't it possible for Data Transfer Object also to have the same definition?
What you mean by Entity here? You mean POCO? If yes then NO DTO and POCO both are not same. A POCO can maintain state and have it's behavior but DTO's are just for transferring the state and have no behavior doesn't maintain any behavior. See Martin Fowler Blog on DTO
Just started developing a project using NHibernate and Fluent NHibernate for the mapping and I'm confused. Since the project is going to get more complex over the next months I would like to structure the code into logical layers such as Persistence Layer and Business Logic layer.
I have a business object called Patient that contains logic and validation.
Should Patient class be mapped with the Fluent NHibernate mapping class?
Or should the mapping class map to some Data Access Object, such as PatientDAO and Patient class somehow use PatientDAO?
If 1, isn't my Business logic layer and persistence layer the same?
If 2, having the two layer is separate projects, should I the BL project contain the Patient object and some IPatientDAO and the PL have the PatientDAO object?
Or am I doing it all wrong? :-)
You should map your entities using Fluent NHibernate, since that is where you map to/from your database structure to your object model.
As for DAO, this is a matter of personal taste. Generally folks like to use a DAO of some sort (even though folks like to call them Repositories these days). These classes will utilize the NHibernate ISession to read/write the data to and from the database. Generally the current means of working with these is to define a generic interface with Get<T>(int id), GetAll<T>(), 'Delete()type methods defined to handle CRUD ops, withT` being the entity type.
It is, however, also possible to use the ISession directly in your presentation code, since it is already providing an abstraction for reading/writing data. If you go this route then you are exposing NHibernate to the rest of your app, but your also removing one level of abstraction.
As for which layer is which, NHibernate is 95%-100% of your persistence layer. You can add some abstractions of your own on top of it to create an API that makes you happy, but that is totally up to you.
Following SRP and KISS principle I designed an object with properties only, but I need methods to work with the objects. What is the best way to separate entity object data and entity set object methods?
Currently I created the following objects:
Pet Entity object
Attribute Name
Attribute Age
Pet Entity Set object
List of Pet objects
Pet Engine object
Method LoadPets of Pet Entity Set
Method GetPetByName of Pet Entity
Method GetPetsByAge of Pet Entity Set
Is this the best way to design the objects?
I'm developing in .net
Thanks.
You've implemented the Anemic Domain Model antipattern. Classes should implement the methods that they need, that doesn't break SRP, but IMHO SRP is way over rated anyway.
The general idea is to keep the methods close to the data they operate on. The construct that combines data and operations is known as a class.
Seriously, why do you think it's a good idea to separate the data from the operations? That's the opposite direction to where we've been going for decades!
Use a functional language with support for pattern matching. Since you're on .net, F# is the obvious choice.
This works well for message oriented systems where you have mostly stateless nodes which transform messages then pass messages to other nodes. In these scenarios, you don't care about mutating the data in the message nor about the identity of message; you care about advancing the processing in each node and sending out more messages.
You're not doing object oriented design, and object oriented languages do not support this paradigm well - they tie a mutable bag of data to an object with identity, rather than creating a reactive system of message transformers.
In effect, this requires you to take the dual of the system - the messages in a reactive system correspond to the method and arguments in object oriented systems. Roughly, the state which is in the fields of the objects of an OO program is kept the call stack of a reactive program, and the state which is the call stack of the OO program is kept in the fields of the messages in the reactive program.
I have an entity class and an entity DAO class.
Should it be the responsibility of the DAO class to create instances of the entity class, or should there be an entity creator/manager class that uses the DAO class only to get the data from the database to create the entity class.
Thanks,
Chris
It should be the responsibility of the DAO to load a persistent object from the datastore and returning a transient instance. Why add another layer of abstraction here?
For creating new Entities, a Factory (or Assembler) might be involved. However, usually this is only justified when entity creation is complex enough. A simple constructor fits the bill just fine in most cases.
I usually let the DAO know about the entity assembly and return a fully hydrated entity. Why? Because, usually the DAO only exists to support that entity. If its role is isn't bound to supporting that entity or related entities, then you may want to look at an intermediate layer.
I'm assuming you're talking about a persistent entity and something that manages that persistence. In my opinion, there is no value in using a factory to simply create the POJO. Use conventional means and then use a DAO, an EntityManager, whatever, to deal with the persistence. I think the key point is not to let the persistence strategy/implementation bleed past your business API.