154 reputation
4
bio website
location
age
visits member for 2 years, 5 months
seen yesterday

Dec
15
awarded  Commentator
Dec
15
comment Best practices for serialization of DDD aggregates
Actually I'm referring to neither of the three kinds of objects you describe, but to "aggregates" in DDD terminology and their sub objects (enities, value objects). I realize now, that my question was not explicit enough about this. Sorry! Please see my edit above.
Dec
15
revised Best practices for serialization of DDD aggregates
added 10 characters in body
Dec
15
revised Best practices for serialization of DDD aggregates
added 10 characters in body
Dec
15
comment Best practices for serialization of DDD aggregates
I agree about public accessors being usually assumed on objects to be serialized. But I would still like to know more about how this relates to DDD and its strong focus on encapsulation of domain logic. Do all DDD practitioners just expose the domain model's state via public accessors for serialization (and never mention it in their examples)? I doubt it. Please don't get me wrong. I appreciate your input very much. It's just that I'm interested in a different aspect. (So far I don't think my question is too vague, but Robert Harvey's answer and yours got me thinking about that..)
Dec
15
comment Best practices for serialization of DDD aggregates
I agree with your view on decoupling. The serializer depends on the domain object and that's OK. But not the other way round. I disagree however with your view on public accessors on domain objects. In practice they often have them, yes. But IMO it would be preferrable to implement domain logic in a clean object-oriented design: Tell, don't ask. But still you need accessors for mapping purposes (ORM, serialization, GUI...). And that's what I would like to avoid, if possible.
Dec
15
comment Best practices for serialization of DDD aggregates
Sorry, but this doesn't answer my question. It's about decoupling domain objects from serialization, not about the reasons for serialization or pros and cons of various formats. How do I serialize domain objects without publicly exposing their private state?
Dec
14
awarded  Supporter
Dec
14
asked Best practices for serialization of DDD aggregates
Aug
22
comment Build filter conditions for entities on client side
At this point I only need WHERE. What I'm struggling with is to come up with an idea for such a simple object. It would have to represent an expression tree in order to allow for flexible expressions and not just chains of ANDs or the like. Also it should limit client developers to options, which are supported by the server. I don't want somebody to provide a filter on an unindexed column, for example.
Aug
22
comment Build filter conditions for entities on client side
So you wouldn't agree, that building SQL on client side only seems simple in the short run? Apart from the fact that our DBAs would probably lynch me, I'd still have to parse the SQL into some kind of simplified expression tree to present it in the GUI. I agree, that this would simplify serialization and persistence.
Aug
21
asked Build filter conditions for entities on client side
Jul
5
revised Software Design Idea for multi tier architecture
added 245 characters in body
Jul
5
answered Software Design Idea for multi tier architecture
Jul
5
comment ORM and component-based architecture
0:n? I assume you mean 1:0 (or 1:*). Anyway, thanks for the clarification!
Jul
5
comment ORM and component-based architecture
Thanks for your answer. So you would agree, that in my scenario there should be a 1:n relationship between 1 data access component and n business logic components?
Jul
5
awarded  Editor
Jul
5
comment ORM and component-based architecture
Edited question. Sorry if it was too vague.
Jul
5
revised ORM and component-based architecture
Clarification, that my issue is only about the fragmentation of data access, NOT about business logic.
Jul
5
comment ORM and component-based architecture
Thanks for your answer! We already have that intermediate layer on the client side in the form of a service facade, which hides the actual service calls from the ViewModels and builds compound objects where appropriate. But that was not my concern. I feel like we deprive ourselves of the relational capabilities of the ORM by cutting the mappings into different components. So I speculated about an ADDITIONAL data access layer with ORM underneath the business layer. The business layer should absolutely stay separated into various components. Should I edit my question to clarify this more?