计算机编程的学习，能不能把知识学到手，讲究的是动手实践。在我编写的文章中，基本都是以实践代码验证结果为核心来讲述文章内容。
可能有人不知道 Netty 是什么，这里简单介绍下：
Netty 是一个 Java 开源框架。Netty 提供异步的、事件驱动的网络应用程序框架和工具，用以快速开发高性能、高可靠性的网络服务器和客户端程序。
也就是说，Netty 是一个基于 NIO 的客户、服务器端编程框架，使用Netty 可以确保你快速和简单的开发出一个网络应用，例如实现了某种协议的客户，服务端应用。
Netty 相当简化和流线化了网络应用的编程开发过程，例如，TCP 和 UDP 的 Socket 服务开发。
这套 IM 代码分为了三组模块：UI、客户端、服务端。
之所以这样拆分，是为了将UI展示与业务逻辑隔离，使用事件和接口进行驱动，让代码层次更加干净整洁易于扩展和维护。
系统设计
在这套IM中，服务端采用DDD领域驱动设计模式进行搭建。将 Netty 的功能交给 SpringBoot 进行启停控制，同时在服务端搭建控制台可以非常方便的操作通信系统，进行用户和通信管理。在客户端的建设上采用UI分离的方式进行搭建，以保证业务代码与UI展示分离，做到非常易于扩展的控制。
另外，在功能实现上包括：完美仿照微信桌面版客户端、登录、搜索添加好友、用户通信、群组通信、表情发送等核心功能。如果有对于实际需要使用的功能，可以按照这套系统框架进行扩展。
解释一下：
1）UI开发：使用JavaFx与Maven搭建UI桌面工程，逐步讲解登录框体、聊天框体、对话框、好友栏等各项UI展示及操作事件；
2）架构设计：使用DDD领域驱动设计的四层模型结构与Netty结合使用，架构出合理的分层框架（相应库表功能的设计）；
3）功能实现：包括；登录、添加好友、对话通知、消息发送、断线重连等各项功能。
功能划分
聊天窗体，相对于登陆窗体来说，聊天窗体的内容会比较多，同时也会相对复杂一些。
1）首先是我们整个聊天主窗体的定义，是一块空白面板，并去掉默认的边框按钮 (最小化、退出等)；
2）之后是我们左侧边栏，我们称之为条形 Bar，功能区域的实现；
3）最后添加窗体事件，当点击按钮时变换 内容面板 中的填充信息。
聊天界面
对话框选中后的内容区域展现，也就是用户之间信息发送和展现。即时通讯开发
从整体上看这是一个联动的过程，点击左侧的对话框用户，右侧就有相应内容的填充。那么右侧被填充对话列表 ListView 需要与每一个对话用户关联，点击聊天用户的时候，是通过反复切换填充的过程。
1）点击左侧的每一个对话框体，右侧聊天框填充内容即随之变化（同时还有相应的对话名称也会也变化）；
2）对话框中左侧展示好友发送的信息，右侧展示个人发送的信息（同时消息内容会随着内容的增多而增加高度和宽度）；
3）最下面是文本输入框，在后面的实现里我们文本输入框采用公用的方式进行设计，当然你也可以设计为单独的个人使用。
好友列表
大家都经常使用 PC 端的微信，可以知道在好友栏里是分了几段内容的，其中包含：新的朋友、公众号、群组和最下面的好友。
1）最上面的搜索框这部分内容不变，和前面的一样。我们目前使用的方式是 fxml 设计，例如这部分是通用功能，可以抽取出来放到代码中，设计成一个组件元素类；
2）经过我们的分析，在使用 JavaFx 组件开发为基础下，这部分是一种嵌套 ListView，也就是最底层的面板是一个 ListView，好友和群组有各是一个 ListView，这样处理后我们会很方便的进行数据填充；
3）另外这样的结构主要有利于在我们程序运行过程中，如果你添加了好友，那么我们需要将好友信息刷新到好友栏中，而在数据填充的时候，为了更加便捷高效，所以我们设计了嵌套的 ListView（如果还不是特别理解，可以从后续的代码中获得答案）。
事件定义
在桌面版 UI 开发中，为了能使 UI 与业务逻辑隔离，需要在我们把 UI 打包后提供出操作界面的展示效果的接口以及界面操作事件抽象类。
以上这些接口就是我们目前 UI 为外部提供的所有行为接口，这些接口的一个链路描述就是：打开窗口、搜索好友、添加好友、打开对话框、发送消息。
在前面我说到更适合的架构，才是符合你当下需要最好的架构。
那么怎么设计需要的架构呢？
之所以这样设计，在这个系统里有如下几点前提：
1）系统在服务端要有 web 页面进行管理通信用户以及服务端的控制和监控；
2）数据库的对象类，不要被外部污染，要有隔离性（比如：你的数据库类暴漏给外部做展示类使用了，那么现在需要增加一个字段，而这个字段又不是你数据库存在的属性。那么这个时候就已经把数据库类污染了）。
3）因为目前都是在 Java 语言下实现 Netty 通信，那么服务端与客户端都会需要使用到通信过程中的协议定义和解析。那么我们需要抽离这一层对外提供 Jar 包（利于重用，不然客户端和服务端复制同样的代码维护，就太恶心了）；
4）接口、业务处理、底层服务、通信交互，要有明确的区分和实现，避免造成混乱难以维护。
结合我们上面这四点的前提，你头脑中有什么模型结构体现了？以及相应的技术栈选择上是否有计划了？
接下来我会介绍两种架构设计的模型，一种是你非常熟悉的 MVC，另外一种是你可能听说过的 DDD 领域驱动设计。