DDD分层架构也分为严格分层架构和松散分层架构，在严格分层架构中，领域服务只能被应用服务调用，而应用服务只能被用户接口层调用，服务是逐层对外封装或组合的，依赖关系清晰。而在松散分层架构中，领域服务可以同时被应用层或用户接口层调用，服务的依赖关系比较复杂且难管理。因此我个人推荐使用严格的分层架构
3.如何选择三层架构还是DDD分层架构对于项目开发中应该如何选择我们可以基于两点考虑：系统本身的业务复杂度和团队人员能力。
3.1 系统本身的业务复杂度如果你们的系统只是个简单的小系统有或者系统本身业务并不复杂，基本都是些增删改查。那么三层架构将是你良好的选择。它会让你的开发变得简单，会大大提高你的开发效率，而且这种分层架构的学习成本很低，新人简单熟悉就可以很容易的上手。对于简单的系统使用DDD分层，反而增加了系统的复杂度。
而如果你们的系统很复杂或者对于一些成长性的网站系统(一开始很小，随着业务发展慢慢壮大的系统)，那么你可以考虑使用DDD分层架构，DDD的思想可以让你更好的对业务进行建模，这种分层架构会让你的系统扩展性很好，在网站壮大的过程中，单体系统必然会向分布式系统进行发展，而DDD的思想可以对服务进行很好的拆分，如当下的微服务架构，DDD的思想就可以帮助我们很好的定义服务的边界。
3.2 团队人员能力团队人员的能力仍然是选择要考虑的因素。因为DDD对于人员的能力要求相对于三层架构要高。它需要团队的人员要有一个良好的逻辑思想和建模能力，而且DDD的学习成本也要高一些。如果你的团队成员能力一般或者以入行不久的新人为主，或者你的团队人员流动性较大的话，也是不建议使用DDD的。这种情况下使用三层架构会更好一些。
总有些人会觉得DDD的概念“高大上”，因此为了使用DDD而使用DDD,更有甚至，根本都没有真正弄明白DDD，就开始使用，最终搞的个四不像，不仅没有解决问题，反而徒增了系统复杂度，拉低性能和效率，其实真正项目中改如何选择，应该结合你的团队和系统来，权衡利弊综合考虑。简单、优雅、方便、快捷的解决问题岂不是更好?
4.两种分层架构对应的代码模型一旦选定了分层架构，项目中所对应的代码模型也就确定了。我们以.net为例(java只需要把程序集当成jar包来看就可以了)，推荐下面这两种代码模型。
4.1 三层架构
这是最简单的三层架构代码模型，业务逻辑层,数据访问层，应用接口层(界面层，界面层可以是mvc，也可以是webapi。（因为现在很多项目都是前后端分离，服务端开发人员不需要写页面，所以就没有写MVC，界面层我也改叫用户接口层了)。。当然现在几乎是没有人这么用的。因为这样做的依赖性很高。不利于扩展。因此我们要引入依赖倒置的概念。因此我们的结构需要做如下变形
这种结构在简单三层的基础上对业务逻辑层和数据访问层引入了其抽象层，这样就很好的将层与层之间的依赖关系进行了解耦。
比如，我曾经遇到多个项目数据库从MSSQL转到MySql。在三层架构中，其实大量的逻辑都应该被封装在业务逻辑层。这个时候我们是需要把DAL换成MySql的DAL，业务逻辑不需要任何改动。如果是最简单的三层架构那种绝对依赖关系，我们必然要改动业务逻辑层以接入新的DAL。而这种依赖倒置的层次结构则不需要。
由于三层架构中同层引用时应该避免的。业务逻辑也是基于数据库模型建立的，而有些业务则需要组合多个业务来实现，为了实现业务逻辑代码复用有些可以采用继承和多态的方式来实现。有些时候则需要再引入一个服务层(防腐层)来组合模块间的交互。也可以把记录日志、验证权限、处理异常等职责分配给这一层。
