分层设计以及每一层的功能：
用户界面层：负责向用户显示和解释用户指令。这里指的用户可以是另一个计算机系统，不一定是使用用户界面的人（比如外部应用调用对应接口）。
网关层： 负责提供对外的HTTP服务或者其他应用层协议（这里是指OSI七层协议中的应用层，别混淆了哈）服务。
应用服务层：定义软件要完成的任务，并且指挥表达领域概念的对象来解决问题。这一层所负责的工作对业务来说意义重大，也是与其他系统的应用层进行交互的必要渠道。应用层要尽量简单，不包含业务规则或者知识，而只为下一层中的领域对象协调任务，分配工作，使他们互相协作。它没有反应业务情况的状态，但是却可以具有另外一种状态，为用户或者程序显示某个任务的进度。
领域服务层：负责表达业务概念，业务状态信息以及业务规则。尽管保存业务状态的技术细节是由基础设施层实现的，但是反应业务情况的状态是由本层控制并且使用的。领域层是业务软件的核心。
基础设施层：为上面各层提供通用的技术能力，为应用层传递消息，为领域层提供持久化机制，为用户界面层绘制屏幕组件（PS：这个在互联网应用中几乎用不到）等等。互联网Web应用系统中基础设施包含了数据持久化服务，中间件服务（数据库，Redis，Memcached，zookeeper，ELK等等）以及第三方服务等。
各层除了实现自己的功能外，还需要遵守以下原则：

每一层设计保持内聚，并且只依赖于它的下方的层。
下层向上层发起的通信只能通过中间件等间接方式进行。[2]
上层和下层只能有松散耦合（各自为独立个体，通过简单引用关联）。在某些微服务框架比如Dubbo中，可以把api包提供给上层引用即可。而Spring Cloud的上下层耦合更为松散，通过契约约定即可。前者的优点是调用者可以直接使用提供方定义好的契约和方法。后者的优点则在于最大限度的降低了耦合，避免在上层无限制的进行下层包引入。

领域的边界很难确定，是因为你对业务不精通，DDD本来就是专门给那些业务专家人用来建模的，刚开始不会区分很正常，，等你有了足够多的项目积累你也就会慢慢区分了，而且一千个人心中有一千个哈姆雷特，每个人区分，肯定都不相同，不能说谁对谁错，应该是谁的最合适

就拿你举得这个例子，注册只是一个动作，根本不能作为一个领域，他只是领域里的一个操作，因为注册，才会增加用户
在我看来，用户可以作为一个领域