Layering and packages
David K Allen
I intend to study your article
http://www.ratio.co.uk/W13.html
more fully as it seems very informative.
But I have a question about packages:
We currently have 20+ applications in our shop.
We have maybe 10-20% of our code in 6 reusable libraries
that are shared by those 20 applications.
But the reusable libraries were structured without good guidelines (but
with good intentions I promise <grin>).
So now I want to refactor and move stuff from one package to another.
But that's very tedious and requires minor namespace and reference
refactoring (.Net technology) in all 20 applications.
And we still have a lot to learn.
So why don't I just shove all 6 reusable libraries into one
giant enterprise reusable library?
Then use folders and namespaces to organize it?
Then I can refactor that easily.
If I ever am satisfied with the high-level structure,
we can split it into appropriate packages again if there is anything to
gain by that.
At first I worried about memory usage of having 20 apps each have a
copy of a large reusable library, but I'm not sure the numbers in our
case make that a serious problem. After all, all 20 applications use
most of these libraries anyway already. Including a few things they
don't need won't make a big difference.
In fact, we can eventually put these in the Global Assembly Cache to be
shared by all the apps, actually reducing memory.
Then I worried about versioning, but that's irrelevant as we use .Net
framework and it allows us to manage that easily (as long as we change
version #s when we change code).
So what do you think of "one big shared package?"
Oh, and have you read "
See larger image
Share your own customer images
Publisher: learn how customers can search inside this book.
Are you the publisher or author? Learn how Amazon can help you make
this book an eBook.
Fundamentals of Object-Oriented Design in UML" by Meilior Page-Jones ?
He offers 4 layers:
Application Domain
Business Domain (shared by applications)
Architecture Domain (platform-specific stuff)
Foundation Domain (int, string, Date, Stack, Queue, etc...)
I like his ideas too.
Respectfully,
David K Allen
Minneapolis, Minnesota
USA
markcol...@gmail.com
I enjoyed your message from April on "Meaning of layering".
I intend to study your article
http://www.ratio.co.uk/W13.html
more fully as it seems very informative.
But I have a question about packages:
We currently have 20+ applications in our shop.
We have maybe 10-20% of our code in 6 reusable libraries
that are shared by those 20 applications.
But the reusable libraries were structured without good guidelines (but
with good intentions I promise <grin>).
So now I want to refactor and move stuff from one package to another.
But that's very tedious and requires minor namespace and reference
refactoring (.Net technology) in all 20 applications.
And we still have a lot to learn.
So why don't I just shove all 6 reusable libraries into one
giant enterprise reusable library?
Then use folders and namespaces to organize it?
Then I can refactor that easily.
If I ever am satisfied with the high-level structure,
we can split it into appropriate packages again if there is anything to
gain by that.
I don't what your libraries do, so it's difficult to say much more. Another problem may be if the dependency structure of the libraries breaks the "depend down" rule of the ARM. Is that the case?
But perhaps (but see above) your solution does the job in the short term, and as you say, you can always attack the bigger problem in the long run, or gradually, splitting out each functionally cohesive library over say six months (like one a month :).
At first I worried about memory usage of having 20 apps each have a
copy of a large reusable library, but I'm not sure the numbers in our
case make that a serious problem. After all, all 20 applications use
most of these libraries anyway already. Including a few things they
don't need won't make a big difference.
See above.
In fact, we can eventually put these in the Global Assembly Cache to be
shared by all the apps, actually reducing memory.
Then I worried about versioning, but that's irrelevant as we use .Net
framework and it allows us to manage that easily (as long as we change
version #s when we change code).
So what do you think of "one big shared package?"
Oh, and have you read "
See larger image
Share your own customer images
Publisher: learn how customers can search inside this book.
Are you the publisher or author? Learn how Amazon can help you make
this book an eBook.
Fundamentals of Object-Oriented Design in UML" by Meilior Page-Jones ?
He offers 4 layers:
Application Domain
Business Domain (shared by applications)
Architecture Domain (platform-specific stuff)
Foundation Domain (int, string, Date, Stack, Queue, etc...)
I haven't read the book. I should probably!
Superficially, though here are my comments on this (but note I'm second guessing the meanings):
- Not having a Interface layer makes the model incomplete - imho. Which layer does UI or External System Interface go in? Probably Application in his terms, but this misses a major objective of the ARM - good code factoring. In the ARM the Interface/Application split means the core business code in the application can be used by many different interfaces. Even within a single application this will increase the intra-project re-use (as per DRY - don't repeat yourself and OAOO - once and only once). It also improves Unit testing as the core business code can be testing using mock-interfaces in Junit style.
- Application domain sounds like Application in the ARM.
- Business domain sounds like Domain in the ARM. Similar objective - potentially shared by Application layer.
- I have problems with Architecture Domain and Foundation Domain. To me they both sound like Platform/Infrastructure in the ARM. Here's the reason:
* both platform specific stuff and language libraries are at the bottom of the dependency chain. They are unlikely to depend on anything else (other than the base OS, which is also Platform).
* both the platform specific and language libraries are generic - can be re-used in any type of application - which is why they have few/no depenendencies on other packages.
Related to this is the Infrastructure/Platform split - which seems to be missed. Although it is a rule that both Infrastructure and Platform contain generic code - there are a couple of major differences:
- you write Infrastructure yourself. Platform is derived externally. Infrastructure can depend on Platform (say wrapping a persistence framework) - but Platform cannot depend on Infrastructure (and won't - it's very unlikely to say the least that an externally sourced package would depend on something you're written yourself!)
- There is a natural package boundary - one key objective of the ARM is that the layers delimit packages - between Infrastructure and Platform. Obviously stuff you bring in is going to be in different packages/namespaces to stuff you write - and the ARM reflects reality in this.
-
Does he have any details rules about using the layers - e.g. depend only down, etc, package can only live in one layer, etc.
If you're really interested in the ARM, we do a one/two day course in it which goes into far more detail than anything published in the whitepapers - see http://www.ratio.co.uk/ARM%20-%20Course%20Outline.pdf
Or fire away with questions... :)!
Ciao,
Mark.