在概念性设计完成后,需要进行架构细化。针对开发编码部分会进行设计开发架构的搭建。这个工作一般会交给项目组或者公司的架构师或者高级程序员来设计完成。
设计者需要根据概念性设计中的将业务功能、非业务功能、质量属性要求进行综合考虑。并着重关注开发期质量属性，例如可扩展性、可重用性、可移植性、易理解性、易测试性等。关注点是在软件开发环境中软件模块的实际组织方式，具体涉及源程序文件、配置文件、源程序包、编译后的目标文件、第三方库文件等。
在进行开发架构设计时，可以参考逻辑架构，将逻辑架构中的逻辑层映射到开发架构中的多个程序包，将逻辑架构中的一个或多个类包含在开发架构中的源码文件中。
开发架构设计应完成的工作：
* 确定要开发或直接利用的程序包之间的依赖关系
* 确定采用的技术
* 确定采用的框架等
分区和分层
因系统的复杂程度不一，需要把系统中的变化点错落有致地封装起来。
分层架构模式为“把变化点封装起来”提供了手段。分层架构的最大优点是将整体问题局部化，把可能的变化分别封装在不同的层中。最终，系统被规划为一个单向依赖的分层体系，利于修改、扩展、替换。从“行政”角度来讲，将架构划分为层的一个很大好处是，这些层形成了开发小组的自然分界----每层的开发人员所需要的技巧是不同的。例如，用户界面层的开发小组需要了解将使用的用户界面工具包有所掌握；数据库管理层的开发小组需要熟悉相关的数据库技能、持久工具或者使用的文件系统......
但有时候仅分层是不足够的。在层中，可能会使用到多个框架，那么我们需要进一步分区，形成横切竖割的“二维架构”。
更进一步，我们还可以把类库和框架的具体用法反映出来。特别是在框架实现了关键的架构机制的情况下，这很有必要。我们知道，框架封装了设计元素之间的交互机制和协作流程，无论框架是自开发的还是第三方实现的，这些设计思想都是架构的一部分。而分区很适合表达应用使用框架的方式：通过类继承或接口实现等手段对扩展点进行扩展。
我们现在开发越来越多地依赖于责成架构，能否切中肯綮地阐明开发和架构的关系，不仅关系到设计思路是否清晰、是否合理，还关系到后续的程序开发工作能否顺畅展开的问题。同时，软件架构为了达到易修改、易测试、易扩展等质量属性需求，必须分离关注点，而在通过展现层、业务层、数据层等进行关注点分离的同时，可以辅以分区方法。框架是分区方法最常用的例子，可以更进一步分离关注点----将应用相关和应用无关的部分分离----将不同变化进行分门别类的封装。
最后需要补充说明的是，分区其实也适用于“逻辑架构的设计。