Changes between Version 10 and Version 11 of application-architecture

Timestamp:

10/17/08 10:04:57 (16 years ago)

Author:

heikki

Comment:

--

application-architecture

@@ -15 +15 @@
   <tbody>
     <tr>
-      <td style="height: 26px; font-weight: bold; width: 190px;">aritifact
+      <td style="height: 26px; font-weight: bold; width: 190px;">artifact
 name</td>
       <td style="height: 26px; font-weight: bold; width: 777px;">responsibililty</td>
@@ -60 +60 @@
 Considerations
  * We could combine services and dao into one artifact named geonetwork-services-ebxml. 
+
+heikki: -1. The dao layer will be used by the domain layer, and although the services layer uses the domain layer, I'd prefer not to tie them in the opposite direction as well.
+
  * We could call the dao artifact persistence.
- * In my other project people are complaining about having more artifacts instead of one for the application. Indeed you need a powerfull computer and IDE. Personally I think that the advantages of more artifacts are greater than the disadvantages. For instance Hudson works on artifact level.  
 
+heikki: hmm. I'm in favor of a layer called 'persistence' and it should sync both the database and the Lucene index. It's not yet clear to me how this relates to the existing codebase, that uses the same database and Lucene index.
+
+ * In my other project people are complaining about having more artifacts instead of one for the application. Indeed you need a powerful computer and IDE. Personally I think that the advantages of more artifacts are greater than the disadvantages. For instance Hudson works on artifact level.  
+
+heikki: +1. For example our domain layer should be a library (JAR) that can be plugged in to any other application, with no dependencies in the code on our other layers. We may produce an application artifact in the form of a WAR or EAR as well though, for ease of installation and distribution. What are we going to do about the current way of creating an "installer" rather than a WAR or EAR ?
+