O'Reilly Forums: brendan.hill - Viewing Profile - O'Reilly Forums

Jump to content

User Rating: -----

Reputation: 0 Neutral
Group:
Members
Active Posts:
1 (0.01 per day)
Most Active In:
Head First C# (1 posts)
Joined:
19-November 12
Profile Views:
496
Last Active:
User is offline Nov 19 2012 03:21 AM
Currently:
Offline

My Information

Member Title:
New Member
Age:
Age Unknown
Birthday:
Birthday Unknown
Gender:
Not Telling Not Telling

Contact Information

E-mail:
Click here to e-mail me

Topics I've Started

  1. Best Practice: Splitting Up Solution Into Many Projects

    19 November 2012 - 01:54 AM

    Hi,

    I recently joined a small software development company (servicing small-medium businesses in the aged care industry) to work on a rewrite of their software in .NET.

    They had a Microsoft consultant lay out a solution framework for them as a starting point based on latest best practice, however the consultant is no longer around and the 3 of us are left with the solution now trying to decide how to proceed. It's early on in development and the architecture can change at our discretion,

    One of my concerns is the modular approach. I know modular is all the rage and it has some tangible benefits, but the downside for us is an unnecessarily elaborate system. Basically every screen in every module has it's own C# project, and another project prefixed with .Domain, and if we add unit tests the projects will be doubled with .Tests, leading to around 100 projects eg.:

    MyCompany.BillingComponent
    MyCompany.BillingComponent.Domain
    MyCompany.BillingComponent.Tests
    MyCompany.BillingComponent.Domain.Tests
    MyCompany.CarePlanComponent
    MyCompany.CarePlanComponent.Domain
    MyCompany.CarePlanComponent.Tests
    MyCompany.CarePlanComponent.Domain.Tests

    etc.

    My question is, what are the other benefits of this modular approach? Do the benefits outweigh the architectural bloat it causes?

    Furthermore, is it appropriate that the Domain be split into modules which directly match the UI modules? I thought Domain represented the business model , and modularization of the interface was a UI level concern.

    My preference is to recommend to the team that we drastically simplify the solution to 3-4 projects (perhaps MyCompany.UI, MyCompany.Domain, MyCompany.Data access, later MyCompany.Tests) but I would like to know both sides before we commit.

    Regards,
    -Brendan

    P.S. This is the second company I've worked at where I've seen each project duplicated with the ".Domain" suffix. I've tried researching this but can't really find much info, is it one way of implementing DDD (Domain Driven Design)?

Friends

brendan.hill hasn't added any friends yet.

Comments

brendan.hill has no profile comments yet. Why not say hello?