Re: Application Services and Framework Annotations

Nikolaos Papagrigoriou <[email protected]>
Newsgroups gmane.comp.programming.domain-driven-design
Message-ID <[email protected]>
Hi Tom,


Thanks for your feedback.


On 10/06/2013 09:53 AM, Tom Eugelink wrote:
>
> I think you have captured the essence of DDD fairly well, but there is 
> always a trade-off between concept and reality; how much work will it 
> be to implement the concept?
>
> Now, annotations are a kind of fleeing construct: they do not have any 
> functionality unless there is a component available in the runtime to 
> act upon them. So when that component is not present, the associated 
> annotations are reduced to the equivalent of some gathered dust; 
> present, slightly annoying, but livable and of no real consequence.
>
> Just for discussion sake, suppose your entities can be persisted in a 
> database or XML files. Keeping it real separate, would mean that in a 
> context where the entities are stored in a database, you would need to 
> create tons of Hibernate XML configuration files. Or likewise for a 
> XML persistence framework.
>
> Now, these configuration files is something that is considered not 
> pleasant nowadays, just adding an annotation to a class is considered 
> much more convenient. The choice to make is whether that 
> "indiscretion" outweighs the configuration files. I think it does.
>
> But there is a limit for the indiscretions to remain acceptable. 
> Including JPA annotations, ok. Also include JAXB annotations... ok. 
> Then adding more annotations because your entities are published and 
> rendered using Apache Isis. Ahhhhmmm. Adding even more annotation 
> because... Somewhere there is a line, but it most certainly is not a 
> hard one.


This is one of my concerns with annotations. I believe that too many 
annotations are a polution to the domain model :-)


In the Java world, annotation based configurations heavily replaced XML 
configuration files. However, in other programming languages e.g. 
Python, configurations could very easily written imperatively (without 
XML). The Pyramid web framework is a good example. See 
http://docs.pylonsproject.org/projects/pyramid/en/1.4-branch/narr/configuration.html 
for an example of imperative and declarative configuration.


I just want to point out that it seems important to me to keep the 
configuration of an application separate from the Domain Model.


Cheers,


Nikos


>
> My 2 cents,
>
> Tom
>
>
> On 2013-09-21 21:10, Nikolaos Papagrigoriou wrote:
>>
>> Hi everybody,
>>
>> In many of the sample DDD applications that I reviewed, framework 
>> specific annotations are used to annotate the Domain Model (e.g. 
>> @Table, @Entity) and the Application Services (e.g. @Transactional, 
>> @PreAuthorize).
>>
>> I believe that the Application Services and especially the Domain 
>> Model should not depend on the framework we are using.
>>
>> Do you agree with the statement above?
>>
>> For example, in the Domain Model we define Repository interfaces that 
>> are implemented in an infrastructure layer. Thus, the Domain Model is 
>> ignorant of the persistence mechanism.
>>
>> Similarly, Application Services manage security and transactions but 
>> depend on Security/Transaction interfaces defined in the Application 
>> layer.
>>
>> Greetings,
>>
>> Nikolaos Papagrigoriou
>>
>>   * English - detected
>>   * English
>>   * Greek
>>   * German
>>
>>   * English
>>   * Greek
>>   * German
>>
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.