169 reputation
6
bio website
location
age
visits member for 2 years, 11 months
seen May 19 at 5:56

May
24
awarded  Tumbleweed
May
17
revised Run fat jar as a service on Amazon Linux EC2 instance using Ansible
added 210 characters in body
May
17
asked Run fat jar as a service on Amazon Linux EC2 instance using Ansible
May
8
awarded  Nice Question
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?