Fear and Loathing

# re: Project Structure - By Artifact or Business Logic?

I go with options 2.  I find that as the project grows you have a larger set of folders, but each folder does not grow.  I would rather deal with fifty folders of 10 items in each folder than 10 folders with fifty items in each.  Generally when you are making a change in a business layer, you more likely to impact multiple files related to functional area than you are to affect multiple interfaces, or multiple constants at once.

# re: Project Structure - By Artifact or Business Logic?

I've always followed Option 2.  One reason it that the groups in Option 1 can continue to grow until they reach an unmaintainable size.  

It's also more likely I'll need to modify a group of related classes/interfaces together than modify all the interfaces.

# re: Project Structure - By Artifact or Business Logic?

Ugh.. I should hit refresh before posting redundant comments.  At least it proves I'm not alone.  The similarity is entirely by accident.

# re: Project Structure - By Artifact or Business Logic?

Why use the file system as the view over how your code structure looks like? Isn't it more efficient to use the class explorer in vs.net ? (and thus it doesn't matter where files are stored?

If you have 200 entities, would option 1 OR 2 still be valuable? I have my doubts though I'd go for option 1 in that case as it is less problematic to find a file.

# re: Project Structure - By Artifact or Business Logic?

Timely topic! We're mulling this over where I work too.

I think option 2 helps convey the domain concepts better. Evans has good advice on this in his Domain Driven Design book:

"Use packaging to separate the domain layer from other code. Otherwise, leave as much freedom as possible to package the domain objects in ways that support their model and design choices." p.115

He takes it even further in chapter 10 with the notion of Conceptual Contours:

"Decompose design elements (operations, interfaces, classes and aggregates) into cohesive units, taking into consideration your intuition of the important divisions in the domain. Observe the axes of change and stability through successive refactorings and look for underlying conceptual contours that explain these shearing patterns. Align the model with consistent aspects of the domain that make it a viable area of knowledge in the first place." p261

By looking at the project structure in option 2, it is easier to see what the major stories, object interactions, and conceptual boundaries are in the system.

I would even take it as far as saying that Constants, Interfaces, Specifications, Value Objects, Enums and Repositories are terms that could hurt more than help in this layer (the IDE will handle the branding for you in most cases). I'd rather a developer name a class the OvertimeQualificationRule rather than the OvertimeQualificationSpecification because it will use vocabulary that a customer, business analyst, project manager, and general user won't have to translate or sit there with glazed over eyes while you discuss it in front of them. It might be a good idea to have a comment that the class is using the Specification pattern, and probably it's base class would tell you that anyway.

In practical terms, a developer will do less folder hopping and walking when working on a story in the domain layer for the second option.

# re: Project Structure - By Artifact or Business Logic?

I'd strongly prefer option #2.  It'd be a much bigger deal without "CTRL-N" though.

# re: Project Structure - By Artifact or Business Logic?

I most definately think that option 2 is the better option. This is the one I am using myself. Especially because it naturally integrates with using namespaces for logical divisions in your code as well.

Option 1 is the dark side.

# Top News Online Business The Business Side of Burning Man Featured in Business 2.0

Pingback from  Top News Online Business  The Business Side of Burning Man Featured in Business 2.0

# re: Project Structure - By Artifact or Business Logic?

I would go with Option 2 too.

As the other posters have said, it is easier if the organisation is done by the module or component as its easier for different developers to work on different parts of the system.

# re: Project Structure - By Artifact or Business Logic?

Hi there,

About how to structure your projects, there is a very nice tool called Tree Surgeon that creates the infrastructure for you, according to what's considered as "best practices".

The tool in itself might not be of great help for you now, but there are also a few articles here:

www.codeplex.com/treesurgeon

balancing the pros and cons of different organizations.

# re: Project Structure - By Artifact or Business Logic?

What a great topic!

I've got a podcast up on this exact thing, although focusing more on things outside the Business Logic. Check out <a href="udidahan.weblogs.us/.../">how to structure .net solutions and components - podcast</a>.

I do something more similar to 2, but different enough to maybe call it 3 :)

I think that I would first be looking at splitting up the service layer into multiple "vertical slices" with each slice handling separate use cases. If I could, from there, find similar fractures in the business logic, I would do that as well.

I'd also look at separating the interfaces (including exceptions) into a separate project. This is based on <a href="udidahan.weblogs.us/.../">my first principle of design</a>.

Finally, I'd go the DDD route of splitting the logic based on aggregate roots.

Does that make sense?

# re: Project Structure - By Artifact or Business Logic?

Option 2 definately! Organizing the hierarchy by types is equivalent to hungarian style naming, very 20th century ;) In the same way  we've moved from using data types to describe our variables to using meaningful names.

Organization by the domain model / functionality is more intuitive and will facilitate locating artifacts more efficiently.

# re: Project Structure - By Artifact or Business Logic?

Wierd, I was about to post in the DDD forum then found this.

We have quite a big code base and have gone for something like option 2 so at the root of the domain you have this sort of structure:

Aggregates

 <Aggregate 1>

   ...

 <Aggregate 2>

Common

  BaseClasses

    ...

  Enumerations

    ...

  Interfaces

    ...

  Value Objects

    ...

Mapping Files

...

The Common folder is there because whats in that folder is used by multiple aggregates, and thats where it gets messy. Looking for an enum, will it be in the Common folder or with a particular aggregate thats the only one that uses it?

Any thoughts on this structure?

# re: Project Structure - By Artifact or Business Logic?

I'd tend towards lucky#2 with one addition: separation of interfaces from the implementations.  So a seperate project with the same folder structure containing only ur interfaces.

#2 also aligns itself more with the service oriented concept where each service is self contained.  

Also, option 1 doesn't lend itself nicely to large distributed groups maintaining discrete chunks of functionality independently.

So forget 'tend' - viva numero due.